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