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

["Philip Oakley" <philipoakley@iee.org>]

From: "Mike Hommey" <mh@glandium.org>
[...]

> 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]


> 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