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

From: Jens Lehmann <jens.lehmann@web.de>
Date: Jan 9, 2014, 08:31 UTC
Message-ID: <52CE5E51.4060507@web.de>
In-Reply-To: <CALas-igFQtG1qa2+grMAtZ9mDE-xGuXkDGwGvSXL8_FzPfXBLQ@mail.gmail.com>

Am 09.01.2014 02:09, schrieb Francesco Pretto:

Show 18 quoted lines

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

Show 15 quoted lines

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

Show 10 quoted lines

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