Thread (26 messages) flat view 26 messages, 4 authors, 2016-06-15

Re: [RFC v2] submodule: Respect requested branch on all clones

From: W. Trevor King <hidden>
Date: 2016-06-15 22:59:33

Possibly related (same subject, not in this thread)

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:
quoted
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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help