git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Is fetch.writeCommitGraph (and thus features.experimental) meant to work in the presence of shallow clones?

From
Taylor Blau <me@ttaylorr.com>
Date
Apr 15, 2020, 00:07 UTC
Message-ID
<20200415000728.GA7382@syl.local>
In-Reply-To
<20200414235057.GA6863@syl.local>
On Tue, Apr 14, 2020 at 05:50:57PM -0600, Taylor Blau wrote:
Show 46 quoted lines
> On Tue, Apr 14, 2020 at 04:31:19PM -0400, Derrick Stolee wrote:
> > On 4/14/2020 4:22 PM, Elijah Newren wrote:
> > > Hi,
> > >
> > > I was building a version of git for internal use, and thought I'd try
> > > turning on features.experimental to get more testing of it.  The
> > > following test error in the testsuite scared me, though:
> > >
> > > t5537.9 (fetch --update-shallow):
> > >
> > > ...
> > > + git fetch --update-shallow ../shallow/.git refs/heads/*:refs/remotes/shallow/*
> > > remote: Enumerating objects: 18, done.
> > > remote: Counting objects: 100% (18/18), done.
> > > remote: Compressing objects: 100% (6/6), done.
> > > remote: Total 16 (delta 0), reused 6 (delta 0), pack-reused 0
> > > Unpacking objects: 100% (16/16), 1.16 KiB | 1.17 MiB/s, done.
> > > From ../shallow/
> > >  * [new branch]      master     -> shallow/master
> > >  * [new tag]         heavy-tag  -> heavy-tag
> > >  * [new tag]         light-tag  -> light-tag
> > > error: Could not read ac67d3021b4319951fb176469d7732e6914530c5
> > > error: Could not read ac67d3021b4319951fb176469d7732e6914530c5
> > > error: Could not read ac67d3021b4319951fb176469d7732e6914530c5
> > > fatal: unable to parse commit ac67d3021b4319951fb176469d7732e6914530c5
> > >
> > > Passing -c fetch.writeCommitGraph=false to the fetch command in that
> > > test makes it pass.
> > >
> > > There were also a couple other tests that failed with
> > > features.experimental=true (in t5500), but those weren't scary -- they
> > > were just checking exact want/have lines and features.experimental is
> > > intended to change those.  This test from t5537 was the only one that
> > > showed some unexpected fatal error.
> >
> > Well, commit-graphs are not supposed to do anything if we have
> > shallow clones. We definitely don't load a commit-graph in that
> > case. Seems like we need an extra check in write_commit_graph()
> > to stop writing in the presence of shallow commits.
>
> This rang a bell to me, too. There's a bug, but it's due to the mutative
> side-effects of 'is_repository_shallow' along with '--update-shallow' (a
> normal 'git fetch' works fine here, with or without
> fetch.writeCommitGraph).
>
> Here's a patch that I didn't sign-off on that fixes the problem for me.

Oh, apparently I did sign this one off ;). I'll blame that 'git commit --amend -vs' is muscle memory for me. In either case, this probably needs some work (if it's even the right approach) before queueing it.

> --- >8 ---
>
> ...

Thanks, Taylor

Previous: Taylor BlauNext: Derrick Stolee
Message 5 of 12 in “Is fetch.writeCommitGraph (and thus features.experimental) meant to work in the presence of shallow clones?”
  1. Elijah NewrenApr 14, 2020
  2. Taylor BlauApr 14, 2020
  3. Derrick StoleeApr 14, 2020
  4. Taylor BlauApr 14, 2020
  5. Taylor BlauApr 15, 2020
  6. Derrick StoleeApr 15, 2020
  7. Taylor BlauApr 15, 2020
  8. Elijah NewrenApr 15, 2020
  9. Jonathan TanApr 16, 2020
  10. Jonathan NiederApr 15, 2020
  11. Elijah NewrenApr 15, 2020
  12. Taylor BlauApr 16, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.