|
Boost : |
Subject: [boost] develop -> master merges
From: Vladimir Prus (ghost_at_[hidden])
Date: 2013-12-18 02:24:01
Hi,
I have a couple questions about merges that I don't think were answered or discussed yet.
- 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?
- 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. In past, 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. What this presumably means, is that I shall do this instead
git merge -no-ff release-1.2
git diff HEAD release-1.2
and if the last command reports any difference, go and fix them by hand. This might be actually better than
'-s theirs', in that if any fix is mistakenly put to 'master' but not merged to 'develop', this diff will
find it, whereas '-s their' will silently wipe it away. But anyway, this 'git diff' invocation probably
shall be documented.
Am I missing something?
Thanks,
Volodya
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk