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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux