Re: Weird behavior of 'git log --before' or 'git log --date-order': Commits from 2011 are treated to be before 1980

From: Thomas Bock <bockthom@cs.uni-saarland.de>
Date: Apr 21, 2023, 14:51 UTC
Message-ID: <1153e31d-2f89-c9dc-8551-adf4d3822487@cs.uni-saarland.de>
In-Reply-To: <7bbcfbc0-f9da-09ef-9441-5e4b13780841@github.com>

Thanks @ all for clarifying this mystery, this already helped a lot to figure out what's going on there.

Even though the affected commit objects are malformed, it would be very helpful if this problem could be solved somehow, from a user perspective. Such malformed objects can potentially occur also in other comparably old projects, where searching for commits that have been made in a specific time window in the past could be useful or even necessary in some cases.

On the other hand, if it would be a huge effort to solve the problem (which I cannot assess), I could fully understand that it might not be worth to completely fix this specific problem that occurs only in few cases in the past (if you are sure that such malformed objects cannot occur any more today). If you decide to not spend the effort on fixing this problem, however, I would appreciate if you could, at least, partially fix this problem by not treating the broken commit objects to be before any other commit object (timestamp 0), but introduce some kind of error handling for such commits that omits listing them in the wrong time period.

Thanks again for all the explanations and thoughts!

Best, Thomas

Am 18.04.23 um 16:02 schrieb Derrick Stolee:

Show 17 quoted lines

> On 4/18/2023 12:12 AM, Jeff King wrote:
>
>> One thing the commit graph perhaps _could_ do is omit the commit, or
>> mark it as "this one is broken in some way". And then fall back to
>> parsing those few instead (which is slower, but if it's a small minority
>> of commits, that's OK). But I don't think there's any code for that.
> The "broken" commit would need to be included in the commit-graph file
> so its children can point to it using a graph position, but then it
> would revert to parsing from the commit object (due to some new concept
> storing "this is a bad commit").
>
> If we decided to treat a timestamp of 0 as "probably broken, artificial
> at best" then we wouldn't need the new indicator in the commit-graph
> file, but this seems like quite a big hammer for a small case.
>
> Thanks,
> -Stolee