2015-11-12 21 views
7

Tôi có các tệp lớn và đang cố gắng sử dụng hệ thống Git LFS mới.Git BFG để khởi động lại các vấn đề cam kết được bảo vệ bởi LFS

tôi đăng câu hỏi này - Git lfs - "this exceeds GitHub's file size limit of 100.00 MB"

Edward Thomson xác định một cách chính xác vấn đề của tôi - bạn không thể sử dụng LFS hồi tố. Anh ấy đề nghị tôi sử dụng BFG LFS support

Điều này đã hoạt động ở mức độ. Phần lớn các tệp của tôi là đã thay đổi. Tuy nhiên, có những cam kết được bảo vệ không bị thay đổi.

Trong số này được bảo vệ cam kết một số đã qua 100.00MB và do đó gây ra một từ xa: lỗi từ github

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

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

* commit c7cd871b (protected by 'HEAD') - contains 165 dirty files : 
    - Directions_api/Applications/LTDS/Cycling/Leisure/l__cyc.csv (147.3 KB) 
    - Directions_api/Applications/LTDS/Cycling/Work/w_cyc.csv (434.0 KB) 
    - ... 

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. 

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. 

Trước hết - ai đó có thể giải thích tại sao những cam kết được bảo vệ và khác biệt so với những người mà BFG thay đổi thành công?

Thứ hai - làm thế nào tôi có thể mở khóa những điều này và cho phép BFG để chỉnh sửa chúng, do đó cho phép tôi sử dụng LFS một cách chính xác và cuối cùng đẩy thành công để GitHub

Trả lời

12

BFG ban đầu được tạo ra như là một công cụ để phá hủy dữ liệu không mong muốn (các tệp lớn, mật khẩu) được chôn sâu trong lịch sử Git. Dữ liệu sẽ là biến mất sau khi BFG chạy và các chương trình thường cần được điều chỉnh để xử lý dữ liệu này không còn trực tiếp nữa (nghĩa là chúng phải được thay đổi để đọc mật khẩu từ biến môi trường hoặc tải xuống phụ thuộc lớn). Các chương trình thích ứng để xử lý những thay đổi này không phải là một bước có thể dễ dàng tự động - con người cần phải cập nhật mã để đối phó với thay đổi đó!

Tôi đã quyết định giả định rằng các dự án đã 'cải cách' - họ đã mắc lỗi trong quá khứ của họ, nhưng vào thời điểm người dùng đến khám phá BFG, họ đã nhận ra sai lầm của mình và ít nhất sẽ có làm sạch các cam kết mới nhất của họ (tức là họ đã thực hiện một cam kết xóa dữ liệu không mong muốn, như là một bước đầu tiên để giải quyết vấn đề). Vì vậy nó là an toàn hơn cho BFG không thay đổi mới nhất cam kết - sự thay thế là cho BFG đến mù quáng dậm tất cả mọi thứ trong lịch sử, bao gồm phiên bản mới nhất của dự án, và thực sự nghỉ phần mềm đó là chưa sẵn sàng để xử lý đọc nó là mật khẩu từ các biến env vv

hành vi này có thể bị vô hiệu hóa bằng cách thêm một --no-blob-protection cờ, ví dụ:

$ java -jar ~/bfg-1.12.7.jar --convert-to-git-lfs '*.{exe,dll}' --no-blob-protection 

tôi có kế hoạch để cập nhật các BFG để ngầm sử dụng --no-blob-protection cờ khi --convert-to-git-lfs tôi hoạt động duy nhất đang được thực hiện - bởi vì đây không còn là hoạt động phá hoại thực sự hoạt động.

Tiết lộ đầy đủ: Tôi là tác giả của BFG Repo-Cleaner.

+0

Giải thích tuyệt vời! Cảm ơn bạn. Sự cố đã được giải quyết :) – LearningSlowly

Các vấn đề liên quan