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:
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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
