GitLab dan LFS Mendorong dengan File yang Hilang

Saya memiliki repositori yang sangat lama yang saya gunakan dan pada titik tertentu beberapa file LFS hilang. Cukup banyak dari mereka. Ketika saya mencoba dan mendorong ke repositori baru di Gitlab, saya mendapatkan kesalahan berikut

 GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual

QA lainnya untuk git-lfs (di sini, di sini) menunjukkan bahwa biasanya beberapa varian git lfs push --all tetapi saya tidak memiliki repo yang berfungsi file-file ini lagi dan hilang selamanya. Gitlab mengabaikan dorongan dengan --no-verify dan masih memberikan kesalahan.

Menjalankan git lfs fetch --all memberikan daftar panjang OID yang hilang

[43cb9e6d1d15bb8d31af911aa69a15a67174c5df73dabc85294ce08198cac468] Object does not exist on the server or you don't have permissions to access it: [404] Object does not exist on the server or you don't have permissions to access it
[454907d530534af9cc95903820c0a632a851b45de98ba18e1de117b8a649f8ac] Object does not exist on the server or you don't have permissions to access it: [404] Object does not exist on the server or you don't have permissions to access it
[ce1314f0c4cb05f349540fa144d33faeb2281ae552cf75dc866a8350d90fd2ac] Object does not exist on the server or you don't have permissions to access it: [404] Object does not exist on the server or you don't have permissions to access it
[d5e8925d273cb00341f00d0f40b39f97cced1e833ef687de2d4663836e7f4e45] Object does not exist on the server or you don't have permissions to access it: [404] Object does not exist on the server or you don't have permissions to access it
...

Postingan lain di sini berisi skrip untuk menghapus LFS sepenuhnya dengan memeriksa setiap melakukan dan mencoreng file LFS, tetapi hal ini tampaknya sangat merugikan repositori di masa mendatang. Yang lain lagi menunjukkan jalur untuk menghapus file LFS seluruhnya (di sini).

Semua masalah ini tampaknya kurang optimal:

  1. Menghapus LFS akan membuat repo membengkak dan noda tersebut kemungkinan besar akan gagal untuk file yang sudah rusak
  2. Git pull/push -all bukanlah suatu pilihan karena file-file tersebut hilang untuk selamanya
  3. Menghapus LFS tidak benar karena versi file yang ada saat ini hanya objek di beberapa cabang di masa lalu yang hilang, jadi semua instruksi tentang cara menghapus LFS akan merusak repo.

Apakah ada cara agar GitLab tidak mengabaikan no-verifikasi atau memfilter OID tertentu secara efisien dari riwayat? Saya tidak keberatan jika file-file tersebut hilang selamanya tetapi saya berharap untuk melestarikan sejarah.

Saya tahu bahwa saya dapat menjalankan git log --all -p -S 43cb9e6d1d15bb8d31af911aa69a15a67174c5df73dabc85294ce08198cac468 untuk mendapatkan komit dan file (walaupun dibutuhkan 5-10 menit untuk menjalankan PER OID, jadi ini akan memakan waktu berjam-jam), tapi saya tidak tahu apa yang harus saya lakukan dengan itu.


git gitlab git-lfs
person Steve    schedule 23.11.2020    source sumber

Jawaban (1)


arrow_upward
2
arrow_downward

Saya baru saja memecahkan masalah yang sama dengan langkah-langkah berikut:

  • Saya mendapatkan jalur relatif file kotor pada git lfs ls-files.
  • Saya mengunduh BFG Repo Cleaner di https://rtyley.github.io/bfg-repo-cleaner/
  • Saya menjalankan bfg dengan meneruskan parameter --delete-files <DIRTY_FILE_PATH>

Log BFG melaporkan kepada saya peringatan berikut:

Protected commits
-----------------

These are your protected commits, and so their contents will NOT be altered:

 * commit 9edf1837 (protected by 'HEAD') - contains 1 dirty file : 
    - requirements/LMD-SE-10-D11/setupse10d11.exe (132 B )

WARNING: The dirty content above may be removed from other commits, but as
the *protected* commits still use it, it will STILL exist in your repository.

Details of protected dirty content have been recorded here :

<REPO_PATH>/..bfg-report/2021-07-30/14-12-39/protected-dirt/

If you *really* want this content gone, make a manual commit that removes it, 
and then run the BFG on a fresh copy of your repo.

Untuk mengatasi peringatan ini, yang mencegah saya menghapus file kotor sama sekali, saya mengkloning repo lagi, tetapi tanpa mencerminkannya.

Sekarang, seperti yang disarankan oleh log, saya menghapus file kotor dengan komit, dan menjalankan lagi perintah BFG dengan argumen yang sama.

Akhirnya, saya mengeluarkan perintah:

git reflog expire --expire=now --all
git gc --prune=now --aggressive

Dan memaksa penulisan ulang sejarah sebesar git push --force.

Hasilnya: referensi LFS yang kotor akhirnya hilang!

person Antonio Petricca    schedule 30.07.2021