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

On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:

2014/1/5 W. Trevor King:

quoted

Adding a check to only checkout submodule.<name>.branch if
submodule.<name>.update was 'rebase', 'merge', or 'none' would be
easy, but I don't think that makes much sense.  I can't see any
reason for folks who specify submodule.<name>.branch to prefer a
detached HEAD over a local branch matching the remote branch's
name.

I think the reason is that it still matches the original use case of
submodules devs:
- the maintainer decides the specific commit developers should have;
- developers checkout that commit and don't pull (you can't do "git
pull" in a detached HEAD);
- they optionally get the upstream commit from the specified
"submodule.<name>.branch" with "--remote". They are still in a
detached HEAD and can't do "git pull".

Maybe who coded submodules at first was thinking that the best way to
contribute to a project is to checkout that repository, and not work
in the submodule. As said, this works well when the submodule
repository is a full project, and not a bunch of shared code.

You're saying that the detached HEAD is a feature because it breaks
pull?  And developers can't be trusted/trained to just not pull
reflexively?  I'm not buying that ;).  Although I was sad to see
jc/pull-training-wheel dropped and have that discussion stall out [1].

quoted

If they prefer checkout updates, the first such update will return
them to a detached HEAD.  If they prefer merge/rebase updates,
future updates will keep them on the same branch.  All my commit
does is setup that initial branch for folks who get the submodule
via 'update', in the same way it's currently setup for folks who
get the submodule via 'add'.

My patch is in the same spirit but wants to obtain the same by being
100% additive and by not altering existing behavior in any way.

My v2 patch doesn't break the current test suite.  I'd be surprised if
a change in such peripheral existing behavior as the post clone-update
branch actually break any user code, but I'd be happy to see links
that prove me wrong.

Also it covers:
- an "autoremote" behavior when the user wants an attached HEAD:
with your patch "--remote" is still needed to really update the
branch with "git submodule update":
- voluntary reattach/detach the HEAD with command line;
- ff-only merge of changes in the case of "checkout" in an attached
HEAD (doing "git checkout <branch>" is not enough);
- reattach of the HEAD with orphaned commits.

Personally, I don't think autoremote updates are worth the additional
UI complication (hence my alternative patch ;), but I'm open to
discussion on this point.  Can you make a case for why and explicit
--remote update is burdensome?

I'm also not entirely clear on the problems avoided or workflows
enhanced via the last two entries.  Could you sketch an example
workflow that makes that more obvious?

Unfortunately our patches are already a bit colliding. I'll wait for
other comments from git maintainers and let see. Anyway, I'm happy
because things are moving: after this debate git submodules will be
better for sure.

+1.  I floated my patch as a proof-of-concept for my side of this
debate, but I'm pretty happy with the current setup, so it's hard for
me to imagine submodules getting worse as a result of this ;).

Cheers,
Trevor

[1]: http://article.gmane.org/gmane.comp.version-control.git/236372

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