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