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

From: Francesco Pretto <ceztko@gmail.com>
Date: Jan 5, 2014, 21:27 UTC
Message-ID: <CALas-ijwb+20dArOGCnZJSqEwU8+ufUpOEktUJ2hAOW_BLpgxw@mail.gmail.com>
In-Reply-To: <d0de817dfc687fd943349c9d3e1d410161a0f01e.1388938473.git.wking@tremily.us>

2014/1/5 W. Trevor King <wking@tremily.us>:

Show 6 quoted lines

> On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote:
>> Also it could break some users that rely on the current behavior.
>
> The current code always has a detached HEAD after an initial-clone
> update, regardless of submodule.<name>.update, which doesn't match
> those docs either.

I perfectly agree with you that the documentation is a bit contradictory with regard to "update" command and detached HEAD. That's why it's so hard to add a feature and keep the same spirit of those that coded submodules at first. Also, I think that submodules didn't get much feedback with regards to these pitfalls because many people try to setup them, they see that "update" detaches the HEAD and they think "hmmm, maybe submodules are not what I was looking for".

Show 6 quoted lines

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

Show 7 quoted lines

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

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.

Cheers, Francesco