[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [RFC/PATCH] add update to branch support for "floating submodules"
From:       Phil Hord <phil.hord () gmail ! com>
Date:       2012-01-31 22:50:02
Message-ID: CABURp0pSGGT8eyzNad-dNNx49oioAxOPOf3dmqu7M3fnV+PzdA () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jan 31, 2012 at 3:55 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> 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.

Sorry.  I type faster than I think sometimes.

I meant that I do use something like this:
    git submodule foreach --recursive 'git checkout master' && git
checkout master

And I expect to use something like this:
    git submodule foreach --recursive 'git push origin topic_foo' &&
git push origin topic_foo

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

Yes, I see what you mean.  In our case, what "happens to be on the
tips" should also have been vetted by our Gerrit+Jenkins code review
dance (for each branch * each superproject), and so it should always
be good.  If it's not, we have the Jenkins-maintained gitlink history
we can use to bisect.

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

Good idea.  Gerrit sees to this for us also, but we do share code on
ancillary git servers and we follow the same practice.

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

What I mean is that a developer may be completely focused on one
particular submodule (his domain).  He does his work in this module,
and when it's ready he commits and pushes to the server.  'git status'
shows him that his directory is clean.  But this is only because he
doesn't really know where the submodules top-directories are, so he
doesn't realize that he has changes in another submodule that he has
not committed.  He has to know to run 'git status' from somewhere in
the superproject (ostensibly in the root directory of that
superproject).  But he may forget since 'git status' already assured
him he was done.

Like this:

#-- Setup
mkdir super && cd super && git init
mkdir A && touch A/foo
git add .
git submodule add gerrit:iptv/iptv_scripts B
git commit -m "Initial commit"

#-- Work flow
cd A && echo changes > foo
cd ../B && echo changes > foo
git add . && git commit -m "Made some changes"
git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

So git just told my new-to-git developer that his workdir is clean
because he happened to run it from super/B.  But if he ran it from
super/A (or super) it would tell him otherwise.

I guess what would help here is something like the opposite of 'git
status' showing the status of descendant submodules;  it would help if
it showed the status of sibling submodules and the superproject as
well.

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

I'm really looking forward to it.

Thanks,
Phil
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]