Điểm của tính năng Đăng xuất trong Git là gì?
git commit --signoff
Khi nào tôi nên sử dụng nó, nếu có?
Điểm của tính năng Đăng xuất trong Git là gì?
git commit --signoff
Khi nào tôi nên sử dụng nó, nếu có?
Câu trả lời:
Đăng xuất là một yêu cầu để nhận các bản vá vào nhân Linux và một vài dự án khác, nhưng hầu hết các dự án không thực sự sử dụng nó.
Nó được đưa ra sau vụ kiện SCO , (và các cáo buộc khác về vi phạm bản quyền từ SCO , hầu hết trong số đó họ chưa bao giờ thực sự đưa ra tòa), như một Chứng nhận Xuất xứ của Nhà phát triển . Nó được sử dụng để nói rằng bạn xác nhận rằng bạn đã tạo ra bản vá được đề cập hoặc bạn chứng nhận rằng theo hiểu biết tốt nhất của bạn, nó được tạo ra theo giấy phép nguồn mở thích hợp hoặc do ai đó cung cấp cho bạn khác theo các điều khoản đó. Điều này có thể giúp thiết lập một chuỗi những người chịu trách nhiệm về tình trạng bản quyền của mã được đề cập, để giúp đảm bảo rằng mã bản quyền không được phát hành theo giấy phép phần mềm miễn phí (nguồn mở) thích hợp không được đưa vào kernel.
Đăng xuất là một dòng ở cuối thông báo cam kết xác nhận ai là tác giả của cam kết. Mục đích chính của nó là để cải thiện việc theo dõi ai đã làm gì, đặc biệt là với các bản vá.
Cam kết ví dụ:
Add tests for the payment processor.
Signed-off-by: Humpty Dumpty <humpty.dumpty@example.com>
Nó phải chứa tên thật của người dùng nếu được sử dụng cho một dự án nguồn mở.
Nếu người bảo trì chi nhánh cần sửa đổi một chút các bản vá để hợp nhất chúng, anh ta có thể yêu cầu người nộp để xác định lại, nhưng nó sẽ phản tác dụng. Anh ta có thể điều chỉnh mã và đặt dấu ở cuối để tác giả ban đầu vẫn nhận được tín dụng cho bản vá.
Add tests for the payment processor.
Signed-off-by: Humpty Dumpty <humpty.dumpty@example.com>
[Project Maintainer: Renamed test methods according to naming convention.]
Signed-off-by: Project Maintainer <project.maintainer@example.com>
Nguồn: http://gerrit.googlecode.com/svn/documentation/2.0/user-signoffby.html
authorlĩnh vực của một cam kết git? Tôi luôn luôn nghĩ rằng đó là lý do có là một riêng authorvà committerlĩnh vực. Tác giả là người viết bản vá và người đi làm là người áp dụng và đẩy bản vá.
git 2.7.1 (tháng 2 năm 2016) làm rõ rằng trong cam kết b2c150d (ngày 5 tháng 1 năm 2016) của David A. Wheeler ( david-a-wheeler) .
(Được hợp nhất bởi Junio C Hamano - gitster- trong cam kết 7aae9ba , ngày 5 tháng 2 năm 2016)
git committrang man bây giờ bao gồm:
-s::
--signoff::
Thêm
Signed-off-bydòng bởi committer ở cuối thông điệp nhật ký cam kết.
Ý nghĩa của việc đăng nhập tùy thuộc vào dự án, nhưng thông thường xác nhận rằng người ủy quyền có quyền gửi tác phẩm này theo cùng giấy phép và đồng ý với Chứng nhận xuất xứ của nhà phát triển (xem https: // developercert ve.org để biết thêm thông tin).
Mở rộng tài liệu mô tả
--signoffSửa đổi các tệp tài liệu (trang man) khác nhau để giải thích chi tiết hơn những gì
--signoffý nghĩa của nó.Điều này được lấy cảm hứng từ " bài báo lwn 'bottomley: Một đề xuất khiêm tốn về DCO' " (Chứng nhận xuất xứ của nhà phát triển) nơi paulj lưu ý:
Vấn đề tôi có với DCO là có thêm "một
-s" lập luận để git commit không thực sự có nghĩa là ngay cả khi bạn đã nghe nói về DCO ( cácgit committrang người đàn ông làm cho không có đề cập đến bất cứ nơi nào DCO ), không bao giờ phiền thực sự nhìn thấy nó.Vậy làm thế nào có thể có sự hiện diện của "
signed-off-by" theo bất kỳ cách nào có nghĩa là người gửi đồng ý và cam kết với DCO? Kết hợp với thực tế tôi đã thấy trả lời trên các danh sách cho các bản vá mà không có SOB không nói gì hơn là "Gửi lại cái này vớisigned-off-byđể tôi có thể cam kết".Mở rộng tài liệu của git sẽ giúp dễ dàng tranh luận rằng các nhà phát triển đã hiểu
--signoffkhi họ sử dụng nó.
Lưu ý rằng hiện tại đăng nhập này (đối với Git 2.15.x / 2.16, Q1 2018) cũng có sẵn git pull.
Xem cam kết 3a4d2c7 (12 tháng 10 năm 2017) của W. Trevor King ( wking) .
(Được hợp nhất bởi Junio C Hamano - gitster- trong cam kết fb4cd88 , ngày 06 tháng 11 năm 2017)
pull: chuyển--signoff/--no-signoffđến "git merge"hợp nhất có thể mất
--signoff, nhưng không kéo--signoffxuống, nó là bất tiện để sử dụng; cho phép 'pull' nhận tùy chọn và chuyển qua.
Có một số câu trả lời hay cho câu hỏi này. Tôi sẽ cố gắng thêm một câu trả lời rộng hơn, cụ thể là về những loại dòng / tiêu đề / đoạn giới thiệu này trong thực tế hiện nay. Nói riêng về tiêu đề đăng xuất không quá nhiều (không phải là tiêu đề duy nhất).
Các tiêu đề hoặc đoạn giới thiệu (↑ 1) như Đăng nhập tắt ((2)), trong thực tế hiện tại trong các dự án như Git và Linux, được cấu trúc siêu dữ liệu một cách hiệu quả cho cam kết. Tất cả đều được thêm vào phần cuối của thông điệp cam kết, sau phần miễn phí hình thức (không cấu trúc) của cơ thể của tin nhắn. Đây là các cặp giá trị mã thông báo (hoặc giá trị khóa ) thường được phân tách bằng dấu hai chấm và dấu cách ( :␣).
Giống như tôi đã đề cập, Đăng nhập vào ra không phải là trailer duy nhất trong thực tế hiện nay. Xem ví dụ về cam kết này , có liên quan đến với Dir Dir Cow Cow:
mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
This is an ancient bug that was actually attempted to be fixed once
(badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
get_user_pages() race for write access") but that was then undone due to
problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").
In the meantime, the s390 situation has long been fixed, and we can now
fix it by checking the pte_dirty() bit properly (and do it better). The
s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
software dirty bits") which made it into v3.9. Earlier kernels will
have to look at the page state itself.
Also, the VM has become more scalable, and what used a purely
theoretical race back then has become easier to trigger.
To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
we already did a COW" rather than play racy games with FOLL_WRITE that
is very fundamental, and then use the pte dirty flag to validate that
the FOLL_COW flag is still valid.
Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com>
Acked-by: Hugh Dickins <hughd@google.com>
Reviewed-by: Michal Hocko <mhocko@suse.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Nick Piggin <npiggin@gmail.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ngoài đoạn giới thiệu đăng nhập trên đường cao tốc ở trên, còn có:
Các dự án khác, như Gerrit, có tiêu đề riêng và ý nghĩa liên quan đến chúng.
Xem: https://git.wiki.kernel.org/index.php/CommitMessageConventions
Tôi ấn tượng rằng, mặc dù động lực ban đầu cho siêu dữ liệu cụ thể này là một số vấn đề pháp lý (đánh giá bằng các câu trả lời khác), thực tế của siêu dữ liệu đó đã tiến triển vượt ra ngoài việc xử lý trường hợp hình thành chuỗi tác giả.
[↑ 1]: man git-interpret-trailers
[2]: Đôi khi chúng còn được gọi là Sob sob (tên viết tắt).
Signed-off-by:dòng thông báo cam kết của dự án nhân Linux (và chính dự án Git). Tuy nhiên, đối với các dự án khác, các dòng như vậy là vô nghĩa trừ khi chuyển nhượng dự án có nghĩa đối với họ (ví dụ bằng cách mô tả chúng trong tài liệu của dự án; ví dụ như Linux SubmittingPatches hoặc Git của SubmittingPatches ).