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

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 09.01.2014 02:09, schrieb Francesco Pretto:
> 2014/1/9 W. Trevor King <wking@tremily.us>:
>>
>> However, submodule.<name>.local-branch has nothing to do with remote
>> repositories or tracking branches.
> 
> My bad: this means the feature is still not entirely clear to me.
> 
>>
>>   [branch "my-feature"]
>>         remote = origin
>>         merge = refs/heads/my-feature
>>         [submodule "submod"]
>>             local-branch = "my-feature"
>>
>> and I don't think Git's config supports such nesting.
>>
> 
> Aesthetically, It doesn't look very nice.

And I'm not sure we even need that. What's wrong with having the
branch setting in the .gitmodules file of the my-feature branch?
The only problem I can imagine is accidentally merging that into
a branch where that isn't set, but that could be solved by a merge
helper for the .gitmodules file.

>> I can resuscitate that if folks want, but Heiko felt that my initial
>> consolidation didn't go far enough [2].  If it turns out that we're ok
>> with the current level of consolidation, would you be ok with
>> "non-checkout submodule.<name>.update" as the trigger [3]?
> 
> For me it was ok with what you did:
> -------------------------------------------------
> if "just_cloned" and "config_branch"
> then
>      !git reset --hard -q"
> fi
> -------------------------------------------------
> 
> So yes: at the first clone 'checkout' keeps attached HEAD, while
> 'merge' and 'rebase' attach to the branch.

It have the impression that attaching the head to the given branch
for merge and rebase might be the sensible thing to do, but it
would be great to hear from users of merge and rebase if that
would break anything for them in their current use cases for these
settings.

> If it's not the first clone, you should take no action (and your
> original patch was ok about this).

I'm not sure this is the right thing to do, after all you
configured git to follow that branch so I'd expect it to be
updated later too, no? Otherwise you might end up with an old
version of your branch while upstream is a zillion commits
ahead.

>>  I think
>> that adding a halfway step between the current status and full(ish)
>> submodule.<name>.local-branch support is just going to confuse people
> 
> Well, for now you got some success in confusing me with this "local-branch" :)
> 
> At certain point  you may ask maintainers what are the accepted
> features (because all these debates should be about getting, or not
> getting, endorsement about something) and finalize a patch so people
> can further review.

First I'd like to see a real consensus about what exactly should
happen when a branch is configured to be checked out (and if I
missed such a summary in this thread, please point me to it ;-).
And we should contrast that to the exact checkout and floating
branch use cases.

So what should happen on initial clone, later updates, updates
where the local and the remote branch diverged, when superproject
branches are merged (with and without conflicts), on a rebase in
the superproject and so on.

After that we can discuss about how to implement them (even though I
believe we won't need a new submodule command at the end of this
process, simply because if it isn't configurable we cannot teach git
checkout and friends to do that automatically for us later).

And from reading this discussion I believe we need another value for
the ignore option which only ignores changes to the SHA-1 but not to
work tree modifications of a submodule work tree relative to its HEAD
(or make that two: another one which ignores untracked files too and
only shows modification of tracked files). Otherwise users of the
floating or attached model can easily miss submodule modifications.