Re: [boost] develop -> master merges

Subject: Re: [boost] develop -> master merges
From: Vladimir Prus (ghost_at_[hidden])
Date: 2013-12-18 07:27:56

On 18.12.2013 15:48, Daniel James wrote:
> On 18 December 2013 07:24, Vladimir Prus <ghost_at_[hidden]> wrote:
>>
>> - Suppose I make a change in the superproject, bootstrap.sh, on develop
>> branch, due to Boost.Build
>>    change. I also want to merge it to master, but I can't really use 'git
>> merge', since it will merge
>>    references to 'develop' versions of all components - not something we want
>> to do. It appears
>>    cherry-pick is what I want to do. I think that's not a problem, as we
>> never modify 'master' directly,
>>    and therefore we won't get any merge conflicts in future. Does anybody see
>> a problem?
>
> There's a problem, but there's a simple solution. Just move content
> out of the super-project. Scripts in the super project should just
> call a script from a submodule which does all the work. Then track
> what's left manually - make sure there's little to track so that it
> shouldn't be too hard. Other than that you'll just have to deal with
> it manually.

It seems that bootstrap.sh is hard to move, it should be at the top
level.

> Another solution is to use Peter Dimov's suggested work flow, since
> with that master was merging in changes from develop. The
> latest/unstable branch could be automatically updated with changes
> from develop.

Yes, Peter's proposal will work just fine, and I think having superproject's
develop branch point and submodule master only sounds confusing, but is in fact
fairly logical.

>
>> - Suppose next release is nearing, and I've tested 'develop' branch of my
>> library, and it works fine.
>>    I want to put it on master (whether I use intermediate release branch is
>> not relevant here). Gitflow say
>>    to use something like this:
>>
>>          git merge --no-ff release-1.2
>>
>>    I imagine that most people want 'master' to be identical to 'develop', or
>> to 'release-1.2',
>>    after such merge, and the above command does not guarantee that.
>
> Generally git-flow ensures that everything in master has been merged
> into develop, since hotfixes and release branches are merged into both
> master and develop. So I think they can only diverge if you've been
> doing tricky things, such as a hotfix which results in a merge
> conflict. In which case you really should be checking that the merge
> result manually before pushing.

In general, yes. If everybody follows the right merge paths, it's OK.
But everybody will eventually forget to.

>> I could use
>>
>>          git merge -s theirs release-1.2
>>
>>    which would make current branch identical to the branch we're merging. But
>> then, git folks decided they
>>    don't like this flexibility, like this:
>>
>>          http://marc.info/?l=git&m=121637513604413&w=2
>>
>>    and removed 'theirs' merge strategy.
>
> I don't agree with the reason for removing '-s theirs', but you can
> still use 'git merge -s ours master' from your release branch.

That would make the release branch be identical to master, so you'd still have
to merge from develop and make sure that merge results are identical to
develop. Well, not a big deal to remember to do this.

- Volodya