RE: "git fetch" fails for a --reference clone after an outer forced push
Thanks!
-----Original Message-----
From: Jeff King <peff@peff.net>
Sent: Thursday, December 26, 2024 8:06 PM
To: Mirochnik, Oleg V <oleg.v.mirochnik@intel.com>
Cc: git@vger.kernel.org
Subject: Re: "git fetch" fails for a --reference clone after an outer forced push
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