# git log date filter bug 2 messages from 2025-01-02 to 2025-01-03. Participants: Sarah Gastner, René Scharfe. Thread: https://gitlist.dev/t/62726 ## Sarah Gastner, 2025-01-02 15:15 Subject: git log date filter bug Message-ID: URL: https://gitlist.dev/e/gEmXX5Orp18U4lUPlWeCKoepi91ih8VkreogEnepOIzTOihbf_iNuXqvdhFcgnIpRabnUscWIKf_GH04iI5NeVpdWjbHnPIPa6ZAtkfITk0%3D%40protonmail.com ``` Good day, 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. Best regards Sarah Gastner Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue. What did you do before the bug happened? (Steps to reproduce your issue) I used the command "git log --after=2023-03-10 before=2024-01-24" in the kubernetes repository (https://github.com/kubernetes/kubernetes), checked out branch master (commit cb93d6ee69b8d4ca8701336e4f7cb278751f34e4). What did you expect to happen? (Expected behavior) The following commit (amongst others) to appear in the output: commit 501976cc34ed3bfea6e1c994d41cb9bc464d6c3b Author: Jiahui Feng Date: Mon Mar 13 14:40:47 2023 -0700 fix broken tests after dependency injection. What happened instead? (Actual behavior) The commit did not appear. What's different between what you expected and what actually happened? Both the author date and the commit date are 2023-03-13. The interval 2023-03-10 to 2024-01-24 should include this date and therefore this commit. Anything else you want to add: I was able to figure out the minimal date interval needed for this commit to appear: 2023-03-07 to 2023-03-14. The following command will only display the commit specified above: git log --after=2023-03-07 --before=2023-03-14 --grep="fix broken tests after dependency injection." If you change the --after date to one day later (2023-03-08), there will be no output. This issue appears in other repositories too. I observed this behaviour on Windows and WSL (Ubuntu). Please review the rest of the bug report below. You can delete any lines you don't wish to share. [System Info] git version: git version 2.47.1.windows.1 cpu: x86_64 built from commit: 2cd22437f64229935dc564db969cbcbfed5e9045 sizeof-long: 4 sizeof-size_t: 8 shell-path: D:/git-sdk-64-build-installers/usr/bin/sh feature: fsmonitor--daemon libcurl: 8.11.0 OpenSSL: OpenSSL 3.2.3 3 Sep 2024 zlib: 1.3.1 uname: Windows 10.0 19045 compiler info: gnuc: 14.2 libc info: no libc information available $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe [Enabled Hooks] Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue. What did you do before the bug happened? (Steps to reproduce your issue) I used the command "git log --after=2023-03-10 before=2024-01-24" in the kubernetes repository (https://github.com/kubernetes/kubernetes), checked out branch master (commit cb93d6ee69b8d4ca8701336e4f7cb278751f34e4). What did you expect to happen? (Expected behavior) The following commit (amongst others) to appear in the output: commit 501976cc34ed3bfea6e1c994d41cb9bc464d6c3b Author: Jiahui Feng Date: Mon Mar 13 14:40:47 2023 -0700 fix broken tests after dependency injection. What happened instead? (Actual behavior) The commit did not appear. What's different between what you expected and what actually happened? Both the author date and the commit date are 2023-03-13. The interval 2023-03-10 to 2024-01-24 should include this date and therefore this commit. Anything else you want to add: I was able to figure out the minimal date interval needed for this commit to appear: 2023-03-07 to 2023-03-14. The following command will only display the commit specified above: git log --after=2023-03-07 --before=2023-03-14 --grep="fix broken tests after dependency injection." If you change the --after date to one day later (2023-03-08), there will be no output. This issue appears in other repositories too. I observed this behaviour on Windows and WSL (Ubuntu). Please review the rest of the bug report below. You can delete any lines you don't wish to share. [System Info] git version: git version 2.45.1.windows.1 cpu: x86_64 built from commit: 965b16798dab6962ada5b0d8cf0dca68f385c448 sizeof-long: 4 sizeof-size_t: 8 shell-path: /bin/sh feature: fsmonitor--daemon uname: Windows 10.0 19045 compiler info: gnuc: 13.2 libc info: no libc information available $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe [Enabled Hooks] Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue. What did you do before the bug happened? (Steps to reproduce your issue) I used the command "git log --after=2023-03-10 before=2024-01-24" in the kubernetes repository (https://github.com/kubernetes/kubernetes), checked out branch master (commit cb93d6ee69b8d4ca8701336e4f7cb278751f34e4). What did you expect to happen? (Expected behavior) The following commit (amongst others) to appear in the output: commit 501976cc34ed3bfea6e1c994d41cb9bc464d6c3b Author: Jiahui Feng Date: Mon Mar 13 14:40:47 2023 -0700 fix broken tests after dependency injection. What happened instead? (Actual behavior) The commit did not appear. What's different between what you expected and what actually happened? Both the author date and the commit date are 2023-03-13. The interval 2023-03-10 to 2024-01-24 should include this date and therefore this commit. Anything else you want to add: I was able to figure out the minimal date interval needed for this commit to appear: 2023-03-07 to 2023-03-14. The following command will only display the commit specified above: git log --after=2023-03-07 --before=2023-03-14 --grep="fix broken tests after dependency injection." If you change the --after date to one day later (2023-03-08), there will be no output. This issue appears in other repositories too. I observed this behaviour on Windows and WSL (Ubuntu). Please review the rest of the bug report below. You can delete any lines you don't wish to share. [System Info] git version: git version 2.47.1.windows.1 cpu: x86_64 built from commit: 2cd22437f64229935dc564db969cbcbfed5e9045 sizeof-long: 4 sizeof-size_t: 8 shell-path: D:/git-sdk-64-build-installers/usr/bin/sh feature: fsmonitor--daemon libcurl: 8.11.0 OpenSSL: OpenSSL 3.2.3 3 Sep 2024 zlib: 1.3.1 uname: Windows 10.0 19045 compiler info: gnuc: 14.2 libc info: no libc information available $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe [Enabled Hooks] ``` ## René Scharfe, 2025-01-03 20:13 Subject: Re: git log date filter bug Message-ID: <5796785f-134b-487b-90e4-e7aaf78cb912@web.de> URL: https://gitlist.dev/e/5796785f-134b-487b-90e4-e7aaf78cb912%40web.de In-Reply-To: ``` 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é ```