Re: [boost] Git: maintaining super-project

Subject: Re: [boost] Git: maintaining super-project
From: Cox, Michael (mhcox_at_[hidden])
Date: 2013-12-05 00:29:44

On Dec 4, 2013 12:40 AM, "Vladimir Prus" <ghost_at_[hidden]> wrote:
>
> On 04.12.2013 11:27, Cox, Michael wrote:
>>
>> On Tue, Dec 3, 2013 at 11:35 PM, Vladimir Prus <ghost_at_[hidden]> wrote:
>>
>>> On 04.12.2013 10:28, Vladimir Prus wrote:
>>>
>>>   As far as I understand, you don't have to create pull requests for
>>>>>
>>>>> master and develop branches. The actual revision is pulled from
>>>>> submodules automatically as you check out the monolithic boost (the
>>>>> boostorg superproject). The pull requests might be needed during the
>>>>> release cycle, if you want specific last minute changes pulled by the
>>>>> release managers so that they get into release.
>>>>>
>>>>
>>>> Well, the superproject has references to specific revisions of each
>>>> component. Or am I mistaken
>>>> on this part?
>>>>
>>>
>>> Looks like I'm not. I did this:
>>>
>>>          ghost_at_solid:~/Sources/boost-modular$ git checkout master
>>>          M       libs/program_options
>>>          Switched to branch 'master'
>>>          ghost_at_solid:~/Sources/boost-modular$ git submodule update
--init
>>>          Submodule path 'libs/program_options': checked out '
>>> fb4f36f3eecbef1e3b4ace5b263e01d56e42d5c7'
>>>
>>> This revision being checked out is what the current superproject repo
>>> specifies, which is 2 commits
>>> behind master of boostorg/program_options library.
>>>
>>> So, yes, without pull request, or manual updates, or some scripting,
>>> checking out the superproject
>>> will not get either 'master' or 'develop' state of all libraries.
>>
>>
>> The following should get you what your asking for, if I understand you
>> correctly:
>>
>> git clone --recursive -b develop https://github.com/boostorg/boost
>
>
> Let's assume that I've already did this, and others checked in more
changes,
> in which case...
>
>
>> git submodule foreach git checkout develop
>
>
> ... this command won't be sufficient, as you'd something like:
>
>         git submodule foreach git fetch

Yes, I was assuming you were starting from scratch, hence the "git clone
...".  But this really isn't sufficient either, since fetch doesn't affect
the working directories.

So my new revised recipes are:

To create a brand new local repository:

        git clone --recursive -b develop https://github.com/boostorg/boost
        git submodule foreach --recursive git checkout develop

For a "stale" repository initially checked out as above, to freshen it up
to the latest in boostorg:

        git pull  # Updates the super-project.
        git submodule foreach --recursive git pull

BTW, there's nothing stopping developers from checking out multiple local
repos.  From my brief exposure to Mecurial, that seemed to be the preferred
method early on (I think they've improved Hg considerably since I looked at
it last).

Even with git's extensive branch handling capabilities, for a given work
flow of work you can substitute a repository for a branch and vice versa,
e.g. one could create a local repository, boost-develop.git where the
develop branch was named master that tracked the upstream repository
boost.git's branch develop.  That would be the more traditional non-gitflow
usage of git.

        git clone --recursive -b develop
https://github.com/boostorg/boost-devel

        git checkout -b master -t origin/develop  # Makes the local master
track the remotes develop branch

I'm not recommending this, just showing how a more traditional git branch
usage could be setup.

Michael

> - Volodya
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost