Re: [boost] develop -> master merges

On 18.12.2013 15:48, Daniel James wrote:

On 18 December 2013 07:24, Vladimir Prus 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