Re: [RFC/PATCH] add update to branch support for "floating submodules"

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

Am 30.01.2012 22:15, schrieb Phil Hord:
> I lost my grip on this thread over the holidays...
> 
> On Tue, Dec 13, 2011 at 4:09 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Am 13.12.2011 15:17, schrieb Phil Hord:
>>>   git pull origin topic_foo && git submodule foreach 'git pull origin topic_foo'
>>>
>>>   git submodule foreach 'git push origin topic_foo' && git push origin topic_foo
>>
>> This sounds to me like you would need the "--recurse-submodules" option
>> implemented for "git pull" and "git push", no?
> 
> Only if I have nested submodules, but yes, we do use --recurs* in our scripts.

I'm confused, push doesn't know the "--recurse-submodules" option
at all yet while pull only does a deep fetch when it is given, the
submodule work trees are not updated to the merge result right now.

>> And I miss to see how
>> floating would help when the tips of some submodules are not ready to
>> work with other submodules tips ...
> 
> By project policy, for any branch, all submodules' tips of the
> same-named branch should be interoperable.  The CI server looks after
> this, as much as he can.

We do the same thing on our CI server, but it can only test some
combinations (even though that tends to show most problems pretty
early). But in the end every superproject is responsible to use a
working set of submodule commits, and I would rather bet on a
combination the CI server tested than on what happens to be on the
current tips.

> I think of branch names as sticky notes (extra-lightweight tags,
> sometimes).  We have linear history in many of our vendor submodules,
> but multiple "branches" indicate where each superproject branch has
> presumably finished integration.

We also add a branch in submodules every time a superproject needs
to move away from the submodules master (so the commits won't get
lost by accident).

>>> But not all my developers are git-gurus yet, and they sometimes mess
>>> up their ad hoc scripts or miss important changes they forgot to push
>>> in one submodule or another.
>>
>> Sure, even though current git should help you some by showing changes
>> in the submodules.
> 
> Real newbies may not even remember to use 'git status' strategically.

Hmm, but then they will screw up things in the superproject too, no?

>>>  Or worse, their pull or push fails and
>>> they can't see the problem for all the noise.  So they email it to me.
>>
>> We circumvent that by not pulling, but fetching and merging in the
>> submodule first and after that in the superproject. You have much more
>> control about what is going wrong where (and can have more
>> git-experienced people help with - or even do - the merges).
> 
> I do that, too, and I wish I didn't have to.  I wish I could safely
> and sanely recover from a conflicted "git pull --recurse-submodules"
> pull from the superproject.

That's what my recursive checkout work is aiming at. Me thinks after
that we will also need some good ideas on how to present and help
solving submodule merge conflicts.

> That is, I wish doing so were as
> straightforward as recovering from the same condition would be if all
> my code were in one repository instead of in submodules.
>
> Which is the gist -- I wish submodules did not make git more
> complicated than it already is.

I think we can make working with submodule much easier than it is
now, the next step being updating all submodule work trees as git
updates the superproject's work tree. Even though I suspect that in
the long run submodules will always be a bit more complicated than
having everything in one repository, I'm confident that will be by
far outweighed by the advantages they bring.