Boost logo

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