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

Re: Allowing weak references to blobs and strong references to commits

From
Philip Oakley <philipoakley@iee.org>
Date
Mar 31, 2015, 19:55 UTC
Message-ID
<1E05987AFD4A4ABCB5515905B517C021@PhilipOakley>
In-Reply-To
<20150331100756.GA13377@glandium.org>
From: "Mike Hommey" <mh@glandium.org>
[...]
Show 24 quoted lines
> So I thought, since commits are already allowed in tree objects, for
> submodules, why not add a bit to the mode that would tell git that
> those commit object references are meant to always be there aka strong
> reference, as opposed to the current weak references for submodules.
> I was thinking something like 0200000, which is above S_IFMT, but I
> haven't checked if mode is expected to be a short anywhere, maybe one 
> of
> the file permission flags could be abused instead (sticky bit?).
>
> I could see this used in the future to e.g. implement a fetchable 
> reflog
> (which could be a ref to a tree with strong references to commits).
>
> Then that got me thinking that the opposite would be useful to me as
> well: I'm currently storing mercurial manifests as git trees with
> (weak) commit references using the mercurial sha1s for files.
> Unfortunately, that doesn't allow to store the corresponding file
> permissions, so I'm going through hoops to get that. It would be 
> simpler
> for me if I could just declare files or symlinks with the right
> permissions and say 'the corresponding blob doesn't need to exist'.
> I'm sure other tools using git as storage would have a use for such
> weak references.
>

The "weak references" idea is something that's on my back list of Toh-Doh's for the purpose of having a Narrow clone.

However it's not that easy as you need to consider three areas - what's on disk (worktree/file system), what's in the index, and what's in the object store and how a coherent view is kept of all three without breakage.

The 'Sparse Checkout' / 'Skip Worktree' (see `git help read-tree`) covers the first two but not the third (which submodules does) [that's your 'the corresponding blob doesn't need to exist' aspect from my perspective]

Show 13 quoted lines
> What do you think about this? Does that seem reasonable to have in git
> core, and if yes, how would you go about implementing it (same bit 
> with
> different meaning for blobs and commits (or would you rather that were
> only done for commits and not for blobs)? what should I be careful
> about, besides making sure gc and fsck don't mess up?)
>
> Cheers,
>
> Mike
>
> 1. a git-remote-hg tool, https://github.com/glandium/git-cinnabar/
> --
Philip
Previous: Mike HommeyNext: Randall S. Becker
Message 2 of 10 in “Allowing weak references to blobs and strong references to commits”
  1. Mike HommeyMar 31, 2015
  2. Philip OakleyMar 31, 2015
  3. Randall S. BeckerMar 31, 2015
  4. Junio C HamanoMar 31, 2015
  5. Mike HommeyMar 31, 2015
  6. Junio C HamanoMar 31, 2015
  7. Jonathan NiederMar 31, 2015
  8. Jonathan NiederMar 31, 2015
  9. Junio C HamanoMar 31, 2015
  10. Mike HommeyMar 31, 2015

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.