Re: [boost] [git] How the blazes are you supposed to update all the submodules?

Subject: Re: [boost] [git] How the blazes are you supposed to update all the submodules?
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-12-19 15:37:59

On 12/19/2013 05:42 PM, Edward Diener wrote:
> On 12/19/2013 10:27 AM, Peter A. Bigot wrote:
>> On 12/19/2013 09:05 AM, Edward Diener wrote:
>>> On 12/19/2013 8:00 AM, John Maddock wrote:
>>>> OK.... so I do a
>>>>
>>>> Git pull
>>>>
>>>> at the top level (note: using TortoiseGit), and I see lots of messages
>>>> in the log indicating which libraries have updates, and judging by the
>>>> time taken they seem to be downloaded (?), but I don't actually see any
>>>> changes in the libraries themselves.
>>>
>>> What are reasons for ever 'pulling' the superproject ?
>>
>> Without trying to find what it's intended to mean for Boost, in normal
>> practice this means: Update to identify the versions of each submodule
>> that are confirmed to interoperate correctly at the head of superproject
>> branch that's being pulled.
>>
>> In other words, the latest successful results of integration testing.
>>
>> "git submodule update" is subsequently required to actually change the
>> contents of the submodule working spaces to contain those versions.
>> It's probably a separate step because that makes it easier to deal with
>> conflicts in specific submodules that were locally modified.
>
> I assume "git submodule update" is done at the superproject level. But
> as other have said, this puts everything back into detached state so
> that one needs to checkout whatever branches one was working on before
> again. Ugh !

This can be automated in a number of ways, including use of git built in 
features such as:

$git submodule update --rebase

--rebase

     This option is only valid for the update command. Rebase the 
current branch onto the commit recorded in the superproject. If this 
option is given, the submodule’s HEAD will not be detached. If a merge 
failure prevents this process, you will have to resolve these failures 
with git-rebase(1). If the key submodule.$name.update is set to rebase, 
this option is implicit.

-- 
Bjørn