Re: "git fetch" fails for a --reference clone after an outer forced push

From: Jeff King <peff@peff.net>
Date: Dec 27, 2024, 04:05 UTC
Message-ID: <20241227040551.GA86251@coredump.intra.peff.net>
In-Reply-To: <SJ0PR11MB58148000A9DCB33CCFD792A0C60D2@SJ0PR11MB5814.namprd11.prod.outlook.com>

On Thu, Dec 26, 2024 at 05:36:34PM +0000, Mirochnik, Oleg V wrote:

Show 6 quoted lines

> But one thing is still confusing and inconsistent IMO - why using
> local path for clone still works (even with the git-gc in both master
> and mirror which removes the obsoleted commit object) while it should
> not (based on your explanation and the "git help clone" snippet you
> provided)
> Could you please clarify?

When clone is given a regular path (and not a file:// url), the "--local" mode optimizations are used by default. And in that mode, all of the objects from the source repo are actually hard-linked into the cloned repo. We still set up a pointer to the --reference repository, but none of its objects will be used immediately (since we should have everything we need by hard-linking the source repo).

So here:

> git clone --reference `pwd`/mirror `pwd`/master local1

...there will be hard-links from local1 to the packs in master. So even if "mirror" gets rid of those objects, there will still be copies in local1.

I think if you were to repack local1, it would drop those duplicate objects (because it passes "-l" to "git-repack" under the hood). And then you'd still be subject to the same problems if "mirror" also gets rid of its copies.

-Peff