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). Cheers, Trevor -- 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
signature.asc
Description: OpenPGP digital signature
