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

Re: git-clone --single-branch clones objects outside of branch

From
Jeff King <peff@peff.net>
Date
Jan 29, 2020, 02:23 UTC
Message-ID
<20200129022354.GA596285@coredump.intra.peff.net>
In-Reply-To
<CAOTb1wecnwXrOqJa-dq1zyS1ydgQ-c_b_GX7FkWzJPtGk6xL3g@mail.gmail.com>
On Tue, Jan 28, 2020 at 05:59:54PM -0800, Chris Jerdonek wrote:
Show 9 quoted lines
> > No, "--reference" behaves as usual.
> 
> On this, I found that --reference does behave differently in the way
> that I suspected. For example, when run with the default --local, I
> found that git-clone will create hard links in the new repo to loose
> objects, even if those objects already exist in the reference
> repository. When run with --non-local, the objects in the reference
> repository weren't copied (I didn't find them in the cloned repo's
> pack file).

Sure, but I'd just consider that the same issue: hardlinking takes everything in the object database without regard to what's needed. So --reference still works (and when you repack and break the hardlinks, it will drop any duplicates as usual), but obviously you have access to the extra hardlinked objects in the meantime.

IOW, I don't think it's worth calling this out in the --reference documentation, but could be in the --local documentation. Because the unusual implication is the same whether --reference is used or not.

Show 7 quoted lines
> So in addition to --single-branch, this seems to be another case where
> `git-clone --local` will ignore the provided options when deciding
> what files inside .git/objects/ to hard-link. It just hard-links
> everything. This is another example of something that I think would be
> worth mentioning in the docs in some form. Currently, the
> documentation for --reference suggests that objects won't be created
> in the new repo if they already exist in the reference repository.
It says:
  Using an already existing repository as an alternate will require
  fewer objects to be copied from the repository being cloned, reducing
  network and local storage costs.

which I think is still technically true. The hardlinks are free in terms of storage (and there's no network cost by definition). So at worst --reference is doing nothing to start with. And the repository has been setup in such a way that it may yield benefits later (after you repack and the hardlinks are broken).

This is maybe splitting hairs a bit. The thing that matters, I think, is where a documentation change should go (and what it should say).

-Peff
Previous: Chris Jerdonek
Message 6 of 6 in “git-clone --single-branch clones objects outside of branch”
  1. Chris JerdonekJan 26, 2020
  2. Jeff KingJan 27, 2020
  3. Chris JerdonekJan 27, 2020
  4. Jeff KingJan 28, 2020
  5. Chris JerdonekJan 29, 2020
  6. Jeff KingJan 29, 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.