On Sun, Jan 05, 2014 at 03:39:43PM -0800, W. Trevor King wrote:
> On Sun, Jan 05, 2014 at 11:57:33PM +0100, Heiko Voigt wrote:
> > The reason why one would set a branch option here is to share the
> > superproject branch with colleagues. He can make sure they can
> > always fetch and checkout the submodule even though the branch there
> > is still under cleanup and thus will be rebased often. The commit
> > referenced by sha1 would not be available to a developer fetching
> > after a rebase.
> Yeah, floating gitlinks are something else.  I'd be happy to have
> that functionality (gitlinks pointing to references) be built into
> gitlinks themselves, not added as an additional layer in the
> submodule script.  This "gitlinked sha1 rebased out of existence"
> scenario is the first I've heard where I think gitlinked references
> would be useful.

On the other hand, if the subproject has such a rebase, a superproject
dev can hop into an existing checkout, update around the rebase, add a
superproject commit with the fixed sha1, and push that for other
superproject devs.  The only people who would need *automatic* rebase
recovery would be superproject devs update-cloning the subproject.
That's a small enough cross-section that I don't think it deserves the
ambiguity of gitlink-to-reference.  In that case, all you really need
is a way to force a recovery gitlink (i.e. add a 'commit' object to
the tree by hand).


This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to