Re: [boost] develop -> master merges

Subject: Re: [boost] develop -> master merges
From: Daniel James (daniel_at_[hidden])
Date: 2013-12-18 06:48:26

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.

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.

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

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