2013-02-01 29 views
24

Tôi hiện đang cố gắng kiểm tra kiểu mã trên PR của kho lưu trữ (github) và tôi muốn phân phối các bản vá cho người gửi mà họ có thể dễ dàng sửa chữa kiểu mã. Để kết thúc này, tôi kéo PR của họ xuống, chạy tập lệnh uncrustify của chúng tôi để sửa bất kỳ lỗi kiểu nào và muốn tạo tệp .patch mà họ có thể dễ dàng áp dụng. Tuy nhiên, nó liên tục phá vỡ trên một số tệp.git-apply không thành công một cách bí ẩn, làm cách nào để khắc phục sự cố/sửa lỗi?

tôi làm (git phiên bản 1.7.10.4 với core.autocrlf=input, core.filemode=false):

$ git checkout pr-branch 
$ git log -1 (shows: commit dbb8d3f) 
$ git status (nothing to commit, working directory clean) 
$ <run the code styler script, which modifies some files> 
$ git diff > ../style.patch (so the patch file lands outside the repo) 
$ git reset --hard HEAD (to simulate the situation at the submitter's end) 
$ git log -1 (shows: commit dbb8d3f) 
$ git status (nothing to commit, working directory clean, so we are where we started) 
$ git apply ../style.patch 
error: patch failed: somefile.cpp:195 
error: somefile.cpp: patch does not apply (same output using the --check option) 

này chỉ áp dụng cho một số tác phẩm, không phải tất cả trong số họ. Tôi không biết làm thế nào để khắc phục sự cố này, tức là làm thế nào để có được git để cho tôi biết chính xác nơi nó đi sai - nó chỉ nói với tôi một hunk # khi tôi đào, nhưng đó vẫn còn khá lớn.

Những gì tôi đã cố gắng cho đến nay (không thành công):

  1. apply --reverse, apply --whitespace=nowarn
  2. diff HEAD thay vì một mình diff
  3. tạo ra một hình nộm cam (! Cam kết tác phẩm mà không vấn đề), sử dụng format-patch , xóa cam kết giả, áp dụng bản vá với git-am có hoặc không có -3 hoặc áp dụng với git-apply
  4. Có tệp bản vá trong lo cal dir thay vì lên (nắm tại ống hút, ở đây)
  5. Kiểm tra người đàn ông-trang-git diff, -apply, -format-vá, -am cho bất cứ điều gì hữu ích
  6. vá với linux patch lệnh
  7. ....

Tôi không biết điều gì có thể sai với điểm khác biệt. Những khoảng trắng chỉ nên cảnh báo, đúng không? Trong mọi trường hợp, tôi sẽ không muốn bỏ qua chúng, vì nó là một kiểu sửa chữa rõ ràng liên quan đến khoảng trắng.

Làm thế nào tôi có thể sửa chữa/chẩn đoán điều này hoặc thậm chí tìm ra nơi nó bails chính xác? Nó sẽ giúp ích nếu tôi đăng sự khác biệt của một trong những tập tin thủ phạm? Điều gì khiến tôi bối rối cũng là ủy ban hoạt động mà không có vấn đề gì, nhưng bản vá được tạo ra từ cam kết không ??

Sau khi vật lộn với điều này trong vài giờ tôi đang ở cuối hiểu biết của tôi ...

+5

'git áp dụng - -reject' để xem các thay đổi bị từ chối. – aragaer

+0

Đã thử rằng ... điều này chỉ hiển thị cho bạn toàn bộ hunk bị lỗi (khoảng 2-300 dòng trong một trường hợp đó), vì vậy không quá thông tin – Christoph

+0

Một giả định khác - có thể có một số tên tệp và có thể đã trở thành 'gitignored' là kết quả. – aragaer

Trả lời

23

Cập nhật:

Bạn có thể sử dụng git apply -v để xem thông tin chi tiết hơn về những gì đang xảy ra, git apply --check để chỉ xác minh hoạt động hoặc git apply --index để xây dựng lại tệp chỉ mục cục bộ.

Dựa trên nhận xét của bạn, có vẻ như chỉ mục cục bộ của bạn đã bị hỏng và do đó, index đã giải quyết vấn đề.

Tôi sẽ để lại câu trả lời ban đầu và nhận xét chủ yếu để cung cấp cho mọi người bối cảnh về những gì đang xảy ra, vì tôi nghi ngờ người khác sẽ chuyển đến cùng một kết luận ban đầu mà tôi đã dựa trên mô tả sự cố.

------

Nhiều khả năng không có gì là sai với diff.Thay vào đó hãy nhìn vào kho lưu trữ git đích. Trong khi bạn đang thực hiện git reset --hard HEAD, không có gì đảm bảo rằng bạn HEAD trên kho lưu trữ khác giống như HEAD trên máy của bạn.

Làm git log trên repo mục tiêu và xem cam kết ở trên cùng. Nó giống như người bạn tạo ra sự khác biệt? Rất có thể là không. Nhìn xuống lịch sử và kiểm tra xem cam kết bạn cần có ở đó không. Nếu có, thì repo mục tiêu ở phía trước của bạn, và bạn phải quay trở lại, làm git pull (hoặc git rebase) và tạo ra một điểm khác biệt mới. Nếu không, thì repo mục tiêu nằm phía sau của bạn, và bạn cần làm git pull (hoặc git rebase) trên repo đích để tăng tốc.

Hãy nhớ rằng nếu bạn có người khác cam kết với repo "chính" của bạn (bot của bạn và kho mục tiêu đang kéo), bạn có thể phải git pull cả hai kho lưu trữ, để đưa chúng đến một cách hợp lý gần đây cam kết chung.

+0

Trong thủ tục tôi đã mô tả ở trên HEAD hiện tại là giống nhau cho cả ứng dụng diff và diff. Đó là cam kết cuối cùng trong nhánh đó. Tôi đặt lại chính xác để loại bỏ bất kỳ vấn đề nào từ các HEAD khác nhau. nên không thể nào. Cập nhật khi cần thiết đã được xử lý tự động, nhưng nếu áp dụng không hoạt động trong tình huống thử nghiệm ở trên, nó sẽ thất bại ở đó, quá, do đó phải được giải quyết trước đó. – Christoph

+0

Nó không rõ ràng từ mô tả của bạn nếu cả hai 'HEAD' trỏ đến cùng một cam kết. Đoán của tôi là họ không, nhưng nếu bạn kiểm tra chúng và họ đang có, sau đó thực sự là một cái gì đó sai với sự khác biệt. –

+0

Ngoài ra, hãy thử 'git apply -v' hoặc chơi với các tùy chọn' --check' và '-index'. –

3

Hãy thử để kiểm tra chống lại vá tập tin của bạn - ví dụ:

git apply --reject mypatch.patch 

này sẽ cho bạn thấy sự khác biệt nếu có - đây là một ví dụ về cách nó có thể trông giống như:

error: patch failed: <filename>:<linenumber> 
error: while searching for : 
    cout << "}" << endl; // example of a line in your patch 
+0

Có vẻ nhưng vẫn có lỗi này –

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