Am 02.01.25 um 16:15 schrieb Sarah Gastner: > I encountered some weird behaviour that I think is a bug. I'll paste > the bug report below and also attach it to this email. The following command shows the offending commit along with its parent, child and grandchild; the format shows commit time, author time, commit hash and parent commit hash: $ git log --format="%ci %ai %h %p" --max-count=4 82eb24156a1 2023-03-08 15:01:06 -0800 2023-03-08 15:01:06 -0800 82eb24156a1 4346c5e5e29 2023-03-07 15:51:09 -0800 2023-03-07 15:51:09 -0800 4346c5e5e29 501976cc34e 2023-03-13 14:40:47 -0700 2023-03-13 14:40:47 -0700 501976cc34e feb18b3f5f9 2023-03-07 15:49:19 -0800 2023-03-07 15:49:19 -0800 feb18b3f5f9 54283a1d383 So 501976cc34e was ostensibly committed six days after its child commit 4346c5e5e29, which would require time travel capabilities. Or, more likely, someone edited the commit history, but did not update the commit times, possibly with git rebase --committer-date-is-author-date. git log assumes that commit dates are chronological and stops traversing the history if it encounters a commit with a timestamp older than the time given with --after. That is a reasonable assumption usually. Not sure what git log could do better here. It could add some slack to the specified time and look deeper than actually asked for to try and catch such time travel artifacts, but how much exactly? History can be arbitrarily deep and history editing can move commits arbitrarily far. Should it go all the way down to the root commits to be safe? That's expensive. Should out-of-order commits be put on some kind of special list for special treatment? Sounds complicated. The current deal of: "You want to mess up commit dates, then tell your collaborators to add some slack to commit date options" is not ideal, but fair in a way. Perhaps someone has a better idea? René
