On Wed, Jun 08, 2022 at 07:17:39PM -0400, Jeff King wrote: > On Wed, Jun 08, 2022 at 04:08:03PM -0400, Derrick Stolee wrote: > > > I'd love to see the full binary, but for the sake of sharing on the > > list, could you give the following output? > > > > xxd .git/objects/info/commit-graph | head > > > > or any other command that shows the first few hex bytes along with > > their ASCII equivalents. Here is one that used Git 2.34.0: > > [...] > > Interesting. My earlier email was a bit misleading. I do in fact have a > GDA2 chunk. And looking at the timestamp on the commit-graph file, it's > from May 24th. I hadn't been keeping the repo up to date regularly, but > I did occasionally pull and rebuild. So I think it was a much more > recent version of Git that built the problematic file, though it's > possible it was carrying forward bad data. > > So 6dbf4b8172ef may be a bit of a red herring, if the file has a GDA2 > section that was simply ignored before that commit. > > Looking at my reflog, my best guess for the version of Git that produced > the file is e46751e96fa. > > > However, the lack of the large offset chunk could be due to the bug fixed by > > 75979d9460 (commit-graph: fix ordering bug in generation numbers, > > 2022-03-01). Perhaps that was the thing that was missing from your version? > > So I _think_ I would have had that, though there's a good chance that an > older version of the commit-graph file was written using a version of > Git without it. > > > But otherwise, I'm stumped. I'd be very interested to see a repro from a > > fresh repository. That is: what situation do we need to be in to write such > > an offset without including the large offset chunk? > > Not exactly a fresh reproduction, but you can grab my broken file from: > > https://peff.net/tmp/broken-commit-graph > > Dropping it into a fresh clone of git.git shows the problem. > > I tried a few obvious from-scratch reproductions like building a file > with 75979d9460^ (so with the generation number bug), and then jumping > forward to e46751e96fa (so bug fixed, but now we write GDA2), but > couldn't get it to trigger. > > It may not be worth spending too much time on, if this is a weird > one-off caused by a mix of buggy unreleased versions of Git. If real > users aren't seeing it, and we know the nuclear option is "rm > commit-graph", then that may be enough. > > -Peff I have also repeatedly run into the same problem. I had already discussed this with Derrick in the past in [1], but back then we also declared bancruptcy and said that this seems to only be caused by some weird in-between states of Git versions. I have experienced the issue again in git.git now, again without having a clue how I arrived at that state. The funny thing is that I explicitly tried to reproduce the error in that repo a few days ago, without any success at all, by writing commit-graphs with different Git versions. Only today when I got back to it completely unsuspecting did Git start to complain. But more imporantly, we started to see the issue in one of our repos in our staging systems as well [2], where we're currently running with a mixture of Git v2.35.1 and v2.36.1 with a small set of patches on top of them. None of the patches are related to commit-graphs though. The repo in question is a pooled repository (like last time I reported the bug), where the pool itself has a single commit-graph with GDAT chunks and the pool member has a single commit-graph with GDA2 chunks. I spent a lot of time today to try and come up with a reproducer to get to this state from a clean repo, but again with no success so far. Also, staring at the code for extended periods of time didn't result in any insights. This issue continues to puzzle me. Patrick [1]: http://public-inbox.org/git/Yh3rZX6cJpkHmRZc@ncase/ [2]: https://gitlab.com/gitlab-org/gitlab/-/issues/365903
Attachment:
signature.asc
Description: PGP signature
