git log không thứ tự thời gian ra lệnh

Question

tôi phát hiện ra bất ngờ trên một dự án công cộng (B2G aka FirefosOS) mà đầu ra git log không thứ tự thời gian đặt hàng:

$ git clone https://git.mozilla.org/releases/gecko.git 
$ git log --graph --format='%C(yellow)%h%Creset %cr %C(blue)%<(7,trunc)%cn%Creset -%C(auto)%d%Creset %<(80,trunc)%s' --all 

* da7ef8a 74 minutes ago B2G B.. - (origin/v2.1) Bumping manifests a=b2g-bump              
* ccf235d 83 minutes ago B2G B.. - Bumping gaia.json for 1 gaia revision(s) a=gaia-bump        
* 653f117 7 hours ago B2G B.. - Bumping manifests a=b2g-bump              
* cc5501b 7 hours ago B2G B.. - Bumping gaia.json for 2 gaia revision(s) a=gaia-bump        
* b4a22de 13 hours ago B2G B.. - Bumping manifests a=b2g-bump              
* 4ad0ee9 13 hours ago B2G B.. - Bumping gaia.json for 2 gaia revision(s) a=gaia-bump        
* 6390e1b 14 hours ago B2G B.. - Bumping manifests a=b2g-bump              
* 9c57530 14 hours ago B2G B.. - Bumping gaia.json for 2 gaia revision(s) a=gaia-bump        
* 07e2a96 3 weeks ago Hsin-.. - Bug 1096128 - [B2G][STK] support call number modified by STK call control. r=a.. 
* 49daf73 3 weeks ago Fredr.. - Bug 1091601 - Settings closes down when changing permissions for THA applicati.. 
* d4bb883 3 weeks ago Rober.. - Bug 1073252. Fix bustage in part 4, a=bajaj          
* 5f3a596 2 days ago B2G B.. - Bumping manifests a=b2g-bump              
* 79bdd97 2 days ago B2G B.. - Bumping gaia.json for 1 gaia revision(s)    

Làm thế nào cũ hơn có thể cam kết được ở phía trước của một ai gần đây?

Hành vi này cũng có thể được quan sát thấy trên giao diện web: https://git.mozilla.org/?p=releases/gecko.git;a=log;h=refs/heads/master

Cảm ơn trước.

EDIT: câu hỏi thực sự là: làm thế nào có thể là một cam kết (d4bb883) có ngày cam kết cũ hơn so với cha mẹ trực tiếp của nó (5f3a596)? Tôi có thể khẳng định rằng đó là phụ huynh trực tiếp vì tùy chọn --graph.

Answer 1

Từ the documentation for git log:

--graph

Vẽ dựa trên văn bản đại diện đồ họa của lịch sử cam kết ở phía bên tay trái của đầu ra. Điều này có thể khiến các dòng phụ được in giữa các lần commit, để cho lịch sử đồ thị được vẽ đúng cách.

[...]

Điều này ngụ ý tùy chọn --topo đặt hàng theo mặc định, nhưng tùy chọn --date-trật tự cũng có thể được xác định.

Và nếu chúng ta nhìn vào các tài liệu hướng dẫn cho các tùy chọn --topo-order:

--topo bậc

Hiện không có cha mẹ trước khi tất cả các con của nó được hiển thị, và tránh hiển thị các cam kết trên nhiều dòng lịch sử xen kẽ.

Ví dụ, trong một lịch sử cam kết như thế này:

---1----2----4----7 
    \    \ 
    3----5----6----8--- 

nơi những con số biểu thị thứ tự của cam kết timestamps, git rev-list và bạn bè với --date-order hiển thị các cam kết theo thứ tự timestamp: 8 7 6 5 4 3 2 1.

Với --topo-order, chúng sẽ hiển thị 8 6 5 3 7 4 2 1 (hoặc 8 7 4 2 6 5 3 1); một số commit cũ hơn được hiển thị trước các commit mới hơn để tránh hiển thị các commit từ hai track phát triển song song được trộn lẫn với nhau.

Vì vậy, vì bạn đang sử dụng git log với --graph, các cam kết mới hơn luôn đặt hàng bên dưới con cái của họ.Vì vậy, nếu bạn có một cam kết cũ hơn là một con của một cam kết mới hơn, nó git log --graph sẽ hiển thị các cam kết cũ hơn trên mới hơn.

Làm thế nào điều này có thể xảy ra? Làm thế nào có thể là một cam kết (d4bb883) có một ngày cam kết cũ hơn so với cha mẹ trực tiếp của nó? Không phải cha mẹ phải có được cam kết đầu tiên? Vâng, dấu thời gian cam kết chỉ là siêu dữ liệu được thêm vào cam kết bởi git, và do tính chất phân tán của git, không có gì ngăn cản các trình liên kết đặt bất kỳ ngày nào họ muốn trên các cam kết mà họ tạo ra. Trong thực tế, git rebase thậm chí còn có tùy chọn đó một cách rõ ràng cho phép bạn "lời nói dối" về cam kết ngày:

--committer-date-là tác giả cập nhật

--ignore-date

Những lá cờ này được chuyển đến git am để dễ dàng thay đổi ngày của các cam kết được rebased (xem git-am[1]).

Và git-am's docs nói:

--committer-date-là tác giả cập nhật

Theo mặc định, lệnh ghi ngày từ tin nhắn e-mail như các cam kết tác giả ngày và sử dụng thời gian tạo cam kết làm ngày bắt đầu. Điều này cho phép người dùng nói dối về ngày bắt đầu bằng cách sử dụng cùng một giá trị với ngày tác giả.

Ngoài --committer-date-is-author-date tuy nhiên, có những cách khác trong đó một ngày cam kết có thể được đặt không chính xác, chẳng hạn như một chiếc đồng hồ hệ thống đặt không chính xác trên máy tính của committer. Vấn đề là, ngày bắt đầu không nhất thiết phải luôn chính xác.

Answer 2

Có thể họ sử dụng hệ thống đánh giá của một số loại (Ví dụ về hệ thống đánh giá như vậy: Gerrit). Vì vậy, các cam kết cũ hơn có thể được xem xét lâu hơn để mất nhiều thời gian hơn để hợp nhất.

Do đó, các cam kết mới hơn có thể được hợp nhất sớm hơn.