On Mon, Jun 29, 2020 at 6:51 PM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > On 6/29/2020 6:07 PM, Jonathan Tan wrote: > > At $DAYJOB, a few people have reported "warning: unable to find all > > commit-graph files" warnings. Their commit-graph-chain files have a few > > lines, but they only have one commit graph file with very few commits. I > > suspected something happening during fetch, because (as far as I know) a > > fetch may cause an incremental commit graph to be written, but I ran a > > fetch on a large repository myself and didn't run into this problem. > > > > Has anyone ran into this problem before, and know how to reproduce? I don't have any specific reproduction steps, but we've just run into our first case of this on Git 2.29. I ended up kicking off a full `git commit-graph write` to fix it. That displayed the same warning, but commands run after it no longer do. Prior to writing the new graph, I had this: $ ls commit-graph-chain graph-88f5fe6e0c659e3742e556982263813d528ead81.graph Afterward, the `objects/info/commits-graphs` directory still exists but is empty, and there is now an `objects/commit-graph` that didn't exist before. `git commit-graph verify` seems happy with the state of things. > > The incremental commit-graph code deletes any commit-graph files > that do not appear in the chain. I believe this is done by comparing > the contents of the ".git/objects/info/commit-graphs/" directory to > the contents of the chain file. > > These appear to be case-sensitive, full-path comparisons. > > It is _possible_ that something like a case switch or a symlink > could be causing a problem here. That's where I would look on > the affected systems. Are commit graphs potentially problematic in repositories that are borrowing objects from other repositories via alternates? Have there been important changes to commit graphs since 2.29? > > Likely the full-path comparison in expire_commit_graphs() should > be dropped in favor of local filename comparisons. A case- > sensitive match is less likely to be important here since Git > is writing the paths itself and should get the proper case back > from the directory listing. > > Thanks, > -Stolee > -b
