Thanks! -----Original Message----- From: Jeff King <peff@xxxxxxxx> Sent: Thursday, December 26, 2024 8:06 PM To: Mirochnik, Oleg V <oleg.v.mirochnik@xxxxxxxxx> Cc: git@xxxxxxxxxxxxxxx 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: > 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
