Re: Ignoring commits when merging

[Mike Strauch <mike.strauch@hannonhill.com>]

Jonathan,

Thanks for the info.  The scenario that I am in is most like the
"Writing a new bugfix" scenario you've described.  We have a
maintenance branch in which the majority of commits are bug fixes.  We
would then like to merge those bug fixes into our master branch.  The
difference being that there will occasionally be a commit in our
maintenance branch that we do not want to merge into our master branch
because it contains application version information which is only
relevant when we release something out of our maintenance branch.  So,
the tree looks like:

              Release

                   |
       ------- previous bug fixes --------- version info commit----
v1.0 --- bug fix commits --- X [maint]
      /                                     \ M1
--- o --------- ...
-------------------------------------------------------------------- N
[master]
               \                                      /
                -----------...--------- F [new feature branch]

You'll also notice I've included a new feature branch here to give
more of a big picture view of our setup.

So, what happens is this:

1. We fix some bugs in the maint branch (previous bug fixes)
2. We test those fixes
3. Merge the fixes back into master (M1)
4. Commit version information to maint branch (version info commit)
5. Release from maint branch (v1.0)
6. Start the process over from step 1 but with the version information
commit in the maint branch commit history.

So, in this scenario there is really only ever 1 commit that we don't
want to be merged into master from the maint branch.  This is not
always the case of course.  There could be some other commits in maint
branch that we don't want to merge back into master.  Anyway, if you
have any more feedback that would be great.  Either way, I'll have to
take a look at the man page you suggested.

Thanks again,

-Mike

On Tue, Aug 17, 2010 at 9:59 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> Mike Strauch wrote:
>
>> I'm fairly new to git and I'm trying to figure out the best way to
>> ignore certain commits when merging one branch into another.
>
> An interesting question.  The answer (as so often) depends on what
> you want to do.  "man 7 gitworkflows" might help.
>
> Below I will pretend you are trying to backport some changes to a more
> stable branch; others may chime in with other scenarios.
>
> First, a general hint: when using git and similar systems, it is
> generally best if each merged result is somehow "better" than all of
> its parents.  I will give an example below of what can go wrong if
> this invariant is violated.
>
> Merging to a maintenance branch
> -------------------------------
>
> Suppose given a history like this (1):
>
>  o --- v1.0 [maint]
>           \
>            feature --- feature --- bugfix --- bugfix [master]
>
> Development has been happening on the "master" branch and now you
> want to merge back the relevant fixes to make a new point release,
> something like the following:
>
> [*] o --- v1.0 ------------------------------------ v1.1 [maint]
>              \                                    /
>               master-only feature --- bugfix --- M [master]
>
>  "a dangerous history"
>
> Let's consider what that would mean.  Someone builds some new
> work off of maint:
>
>  o --- v1.0 --- v1.1 --- o ... o --- A [someone]
>               /
>
> What happens when you pull the "someone" branch into master?  The
> relevant piece of history looks like this:
>
>        v1.1 --- o ... o --- A [someone]
>       /
>  ... M --- new development --- ... --- B [master]
>
> When you try to pull A into B, git runs a three-way merge to
> apply the changes from the someone branch after the branch point (M)
> on the master branch.  In particular, the changes from M to v1.1
> are pulled in.  The main change from M to v1.1 is to drop a
> bunch of features.  So by pulling from someone, you lose features
> on the master branch.
>
> So a merge like [*] that drops desirable changes is generally not
> a good idea.
>
> Cherry-picking to a maintenance branch
> --------------------------------------
>
> As a result, starting from a history like (1), there is only one
> choice: cherry-pick only the bugfixes, so the new features are not
> incorporated into the history of the maint branch.
>
>  $ git checkout maint
>  $ git cherry-pick bugfix1 bugfix2
>
> Afterwards, it is best to merge the maint branch into master, so
> later changes on the maint branch can be merged into master more
> easily.  Usually despite the duplicate changes will not result in
> conflicts.
>
>  $ git checkout master
>  $ git merge maint
>  $ git diff HEAD^
>  $ : looks good
>  $ git push public maint master
>
> If there are conflicts, no need to worry: make sure that "master"
> really includes all desirable changes from maint and merge with
> strategy ours instead.
>
>  $ git reset --merge
>  $ git merge -s ours maint
>
> Writing a new bugfix
> --------------------
>
> Suppose you have an idea for a new bugfix.  As discussed above, if
> you write it directly on top of master, when it is time to apply
> it to maint it will need cherry-picking.  If you base the patch
> on maint, you can avoid that:
>
>  $ git checkout -b bugfix maint
>  ... hack hack hack ...
>  $ make test
>  $ : looks good
>  $ git checkout master
>  $ git merge bugfix
>  $ make test
>  $ git push public bugfix master
>
>  v1.1 [maint] --- X [bugfix]
>     \             \
>      o --- ... --- N [master]
>
>
> Once the patch gets enough testing from users of master, it is
> time to apply it to maint.
>
>  $ git checkout maint
>  $ git merge bugfix
>  $ make test
>  $ git checkout master
>  $ git merge maint
>  $ git push public maint master
>
>  v1.1 ----------- X [maint]
>     \             \
>      o --- ... --- N [master]
>
> One benefit of this approach is that during development, the patch
> is tested against the maintenance branch, which is incidentally
> probably where it is most important that it get testing.
>
> Hope that helps,
> Jonathan
>