From: "Mike Hommey" <m...@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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
