Git 'nghiêm trọng: Không thể ghi tệp chỉ mục mới'

Tôi đã thấy nhiều chủ đề khác về điều này và chúng không giúp ích gì.

Tôi có một repo rất đơn giản - hai tệp JavaScript. Tôi có hơn 100 GB trên Macbook. Khi tôi cố gắng di chuyển các tệp vào một thư mục con và hiển thị cục bộ những thay đổi mà tôi nhận được ...

nghiêm trọng: Không thể ghi tệp chỉ mục mới

Điều này xảy ra cho dù tôi thực hiện tất cả các hành động trong thiết bị đầu cuối hay nếu tôi sử dụng GUI như SourceTree. Ngoài ra, một trong các tệp bị khóa và tôi không thể xóa thư mục đang làm việc cho đến khi tôi đăng xuất và đăng nhập lại.

Tại sao chuyện này đang xảy ra? Có phải khóa đang ngăn thứ gì đó dàn dựng không? Nếu vậy, tôi phải làm gì / làm cách nào để mở khóa tệp sự cố trên OS X ?? Repo từ xa là Google Code, nếu điều đó tạo ra sự khác biệt, mặc dù tôi chưa đẩy đến điều khiển từ xa. Mọi thứ đều là địa phương.

Trong trường hợp của tôi, đĩa hết dung lượng, vì vậy tôi phải xóa các tệp khỏi ổ cứng để tạo dung lượng.

Tôi đã gặp vấn đề tương tự trong vài ngày qua. Về cơ bản, toàn bộ kho lưu trữ đã được chuyển sang một hệ thống tệp mới mà tôi không biết, khi tôi cố gắng chạy trạng thái git, nó đột nhiên thông báo rằng mọi tệp trong repo đã được cập nhật.

Phương pháp khả thi

Vì vậy, sau nhiều lần tìm kiếm trên google, tôi đã thử những cách sau:

• thay đổi hoán vị .git (cùng một vấn đề)
• thay đổi quyền .git / index (cùng một vấn đề)
• git bổ sung tất cả các thay đổi để cam kết (cùng một vấn đề)
• git rm-ing các tệp đã bị xóa, vì chúng báo cáo lỗi tên tệp quá dài (cùng một vấn đề)
• git reset (soft | Head | Hard) (vấn đề tương tự)
• git sạch (cùng một vấn đề)
• tắt trình bảo vệ cửa sổ (cùng một vấn đề)
• đang cập nhật git (cùng một vấn đề)
• các ứng dụng git khác nhau (tôi sử dụng gitbash) (cùng một vấn đề)
• uống 2 cà phê thay vì 1 (cùng một vấn đề)

tl: dr - dung dịch bẩn

Điều duy nhất quản lý để giải quyết vấn đề là sao chép tệp chỉ mục, xóa bản gốc và đổi tên bản sao.

Tôi biết nó không thực sự là một 'giải pháp' nhưng bây giờ nó hoạt động kỳ diệu> <, với tất cả các tệp / nhánh còn nguyên vẹn. Nếu ai đó biết tại sao điều này có thể có hiệu quả, hãy cho biết.

Trong trường hợp của tôi, tạm dừng đồng bộ hóa hộp kéo thả đã giải quyết được sự cố

Tôi đã gặp vấn đề tương tự trên máy Mac. Nó có vẻ là do ACL hệ thống tệp gây ra. Cố gắng chmod -RN /path/to/repoxóa ACL. Sau khi làm điều này, tôi đã có thể thực hiện các thay đổi. Sử dụng thủ thuật sao chép tệp chỉ mục, xóa bản gốc và di chuyển bản sao trở lại cũng đạt được kết quả tương tự.

Nếu bạn đã thiết lập github của mình trong một số loại dịch vụ đồng bộ hóa trực tuyến, chẳng hạn như google drive hoặc dropbox, hãy thử tắt đồng bộ hóa vì dịch vụ đồng bộ hóa cố gắng đọc / ghi vào tệp vì github cố gắng làm như vậy, dẫn đến github không hoạt động một cách chính xác.

Tôi đã xảy ra trường hợp tệp .git / index đang được sử dụng bởi một quy trình khác (máy chủ web phát triển cục bộ của tôi). Tôi tắt quá trình và sau đó nó hoạt động.

Đóng Visual Studio Code (trong trường hợp của tôi có công việc nền trình tải lên tự động đang chạy khi lưu tệp) đã giải quyết được vấn đề cho tôi.

Tín dụng cho giải pháp: bạn tôi và đồng nghiệp Arnel.

Điều này đã làm việc cho tôi:

rm -f ./.git/index.lock

Trong trường hợp của tôi, giải pháp chỉ là thêm quyền cho người dùng mới.

Khi tôi cài đặt hệ điều hành mới, di chuyển các kho của tôi xung quanh và nó hiển thị lỗi chính xác này, tôi đã chọn thư mục gốc và sau đó thêm xác thực người dùng để kiểm tra tất cả

Tôi đã có ACL (bằng cách nào đó) được đính kèm vào tất cả các tệp trong thư mục .git.

Kiểm tra nó với ls -letrong thư mục .git.

Bạn có thể xóa ACL bằng chmod -N(cho một thư mục / tệp) hoặc chmod -RN(đệ quy)

Tôi nghĩ rằng một số giải pháp sao lưu nền như Google Backup and Sync chặn quyền truy cập vào tệp chỉ mục. Tôi đã đóng ứng dụng và Sourcetree không gặp vấn đề gì. Có vẻ như Dropbox cũng làm như vậy (@tonymayoral).

Trong trường hợp của tôi, đó là một EGit chạy đồng thời. Sau khi khởi động lại nhật thực, nó hoạt động như bình thường.

Nếu bạn đang sử dụng hộp Windows, hãy đảm bảo rằng chương trình bạn đang sử dụng, cho dù đó là Cây nguồn hay thiết bị đầu cuối git, đang chạy với tư cách quản trị viên. Tôi đã nhận được cùng một thông báo lỗi chính xác. Bạn có thể nhấp chuột phải vào chương trình để chạy với tư cách quản trị viên hoặc thay đổi các thuộc tính của nó để luôn chạy với tư cách quản trị viên.

Không có đủ không gian là một vấn đề. Dọn dẹp và thử lại

Tôi đã từng gặp vấn đề tương tự. Tôi đã khởi động lại máy tính của mình và sự cố đã được giải quyết.

bạn đã thử 'git add.' . nó sẽ thay đổi tất cả? (bạn có thể xóa các tệp thêm vào không cần thiết bằng git reset HEAD)

Thông báo lỗi fatal: Unable to write new index filecó nghĩa là chúng tôi không thể ghi nội dung mới vào tệp chỉ mục git .git\index(Xem tại đây để biết thêm thông tin về chỉ mục git). Sau khi xem xét tất cả các câu trả lời cho câu hỏi này, tôi tóm tắt các nguyên nhân gốc rễ sau:

• Kích thước của nội dung mới vượt quá dung lượng khả dụng của đĩa. ( Giải pháp : Làm sạch không gian đĩa)
• Người dùng không có quyền truy cập vào tệp này. ( Giải pháp : Cấp quyền)
• Người dùng có quyền nhưng .git\indexbị khóa bởi người dùng hoặc quy trình khác. ( Giải pháp : Mở khóa tệp)

Liên kết Tìm ra quy trình đang khóa tệp hoặc thư mục trong Windows chỉ định cách tiếp cận sau để tìm ra quy trình đang khóa một tệp cụ thể:

SysInternals Process Explorer - Đi tới Tìm> Tìm Xử lý hoặc DLL. Trong hộp văn bản "Xử lý hoặc chuỗi con DLL:", hãy nhập đường dẫn đến tệp (ví dụ: "C: \ path \ to \ file.txt") và nhấp vào "Tìm kiếm". Tất cả các quy trình có xử lý mở tệp đó sẽ được liệt kê.

Sử dụng phương pháp trên để tìm tiến trình bị khóa .git\indexvà sau đó dừng thực thi khóa. Điều này mở khóa .git\index.

Ví dụ: Tìm kiếm Trình khám phá cho thấy rằng .git\indexbị khóa bởi vmware-vmx.exe. Việc tạm ngưng máy ảo VMWare Player (đã truy cập vào kho git thông qua thư mục được chia sẻ) đã giải quyết được sự cố.

NẾU BẠN NHẬN ĐƯỢC THỜI GIAN TRẢ LẠI NÀY:

Điều này rất có thể xảy ra do một số phần mềm khóa tệp chỉ mục trong kho của bạn, chẳng hạn như phần mềm sao lưu, chống vi-rút, IDE hoặc các ứng dụng khách git khác.

Trong hầu hết các trường hợp, khóa chỉ là trong một khoảnh khắc ngắn và vì vậy nó chỉ xảy ra không đúng lúc và không may mắn.

Tuy nhiên, git rebase --continuesẽ phàn nàn về lệnh tiếp theo là một cam kết trống:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Để khắc phục điều này, chỉ cần chạy git resetvà thử git rebase --continuelại.

Sự cố: Khi tôi kiểm tra một số tệp đã sửa đổi trong git, đã gặp lỗi này. Tôi có hai người dùng ABC và XYZ. tệp đang có uid: gid của ABC nhưng nó không có quyền truy cập git và cố gắng kiểm tra các tệp có giống nhau.

Giải pháp tôi đã thử: XYZ đang có quyền truy cập git, đã thử kiểm tra các tệp bằng sudo và nó đã hoạt động .. !!

Đây là những gì đã làm việc cho tôi:

Bối cảnh:

1. Xây dựng dự án trên máy chủ

2. git status trả về một HEAD detached at <commit-SHA>

3. Tôi đã từng thao tác cục bộ, tôi gặp lỗi này. Cụ thể hơn:

   • thanh toán git
   • git reset HEAD --hard

Giải pháp

1. Đơn giản chỉ cần xóa tệp <work-dir>/.git/index.
2. A git statussẽ chỉ ra rằng tất cả các tệp trong projet không được theo dõi (không có gì ngạc nhiên ở đây).
3. git reset HEAD --hard
4. Quay lại HEAD detached at <commit-SHA>khi làm một git status, nhưng sau đó bạn sẽ có thể
5. git checkout <some-branch>

và bạn đã trở lại đúng hướng!

!! QUAN TRỌNG !!

Điều này chỉ hoạt động vì tôi đang xây dựng "vui vẻ". Không có sửa đổi quý giá nào được thực hiện trên mã. Nếu bạn thực sự đang ở "dev-time", thì tôi khuyên bạn nên lưu công việc của bạn trước hoặc chuyển sang phương pháp khác.

Hy vọng nó sẽ giúp ích :).

Tôi gặp sự cố này khi sử dụng GitExtensions trên windows. Đã khắc phục sự cố bằng cách cấp toàn quyền cho người dùng hiện tại (tôi) trên thư mục chứa repo.

Một lần khác, tôi mặc dù gặp lỗi từ Tiện ích mở rộng Git, nhưng tôi vẫn có thể cam kết các tệp tương tự từ Visual Studio 2015.

Một lần khác, tôi phải xóa tệp "chỉ mục" khỏi thư mục .git

Trường hợp của tôi hơi thú vị:

Tôi chạy git log để kiểm tra một cam kết nào đó, sau đó tôi không thoát nó đúng cách, tôi nhấn ctrl + c để thoát nó.

Sau đó, chỉ mục dường như đã bị khóa. Vì vậy, tôi chạy lại git log, sau đó nhấn Q để thoát khỏi nó.

Đã khắc phục sự cố. :)

Trong trường hợp của tôi, đó là một nodemonví dụ xem hệ thống tệp để tìm các thay đổi.