{"thread":{"id":"24774","subject":"Ignoring commits when merging","startedAt":"2010-08-17T20:21:01Z","lastAt":"2010-08-18T23:38:09Z","messageCount":4,"participants":["Mike Strauch","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"148305","messageId":"AANLkTi=B9gsroJS_6SRqa2CLQOed2UguxN7KiFtFWL8t@mail.gmail.com","threadId":"24774","inReplyTo":null,"subject":"Ignoring commits when merging","fromName":"Mike Strauch","fromEmail":"mike.strauch@hannonhill.com","sentAt":"2010-08-17T20:21:01Z","receivedAt":"2010-08-17T20:21:01Z","isPatch":false,"sender":{"key":"mike.strauch@hannonhill.com","avatar":null},"body":"Hi,\n\nI'm fairly new to git and I'm trying to figure out the best way to\nignore certain commits when merging one branch into another.  I've\nfound a solution that suggests that I merge everything before the\ncommit I want to skip, then merge the commit I want to skip using the\n\"ours\" merging strategy, then merge everything after the skipped\ncommit.  This sounds like an adequate solution to the problem, but I'm\nwondering if there's a better way to do it.\n\nI was thinking that I could just cherry-pick the few commits that I\nwant from Branch 2 in order to exclude the commit I don't want, but\nthis will result in there being no link between the branches for those\ncommits.  Are there any other ways this can be done?\n\n--\nMike Strauch\nwww.hannonhill.com\n"},{"id":"148330","messageId":"20100818015947.GA19632@burratino","threadId":"24774","inReplyTo":"AANLkTi=B9gsroJS_6SRqa2CLQOed2UguxN7KiFtFWL8t@mail.gmail.com","subject":"Re: Ignoring commits when merging","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-18T01:59:47Z","receivedAt":"2010-08-18T01:59:47Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nMike Strauch wrote:\n\n> I'm fairly new to git and I'm trying to figure out the best way to\n> ignore certain commits when merging one branch into another.\n\nAn interesting question.  The answer (as so often) depends on what\nyou want to do.  \"man 7 gitworkflows\" might help.\n\nBelow I will pretend you are trying to backport some changes to a more\nstable branch; others may chime in with other scenarios.\n\nFirst, a general hint: when using git and similar systems, it is\ngenerally best if each merged result is somehow \"better\" than all of\nits parents.  I will give an example below of what can go wrong if\nthis invariant is violated.\n\nMerging to a maintenance branch\n-------------------------------\n\nSuppose given a history like this (1):\n\n o --- v1.0 [maint]\n           \\\n            feature --- feature --- bugfix --- bugfix [master]\n\nDevelopment has been happening on the \"master\" branch and now you\nwant to merge back the relevant fixes to make a new point release,\nsomething like the following:\n\n[*] o --- v1.0 ------------------------------------ v1.1 [maint]\n              \\                                    /\n               master-only feature --- bugfix --- M [master]\n\n  \"a dangerous history\"\n\nLet's consider what that would mean.  Someone builds some new\nwork off of maint:\n\n o --- v1.0 --- v1.1 --- o ... o --- A [someone]\n               /\n\nWhat happens when you pull the \"someone\" branch into master?  The\nrelevant piece of history looks like this:\n\n        v1.1 --- o ... o --- A [someone]\n       /\n  ... M --- new development --- ... --- B [master]\n\nWhen you try to pull A into B, git runs a three-way merge to\napply the changes from the someone branch after the branch point (M)\non the master branch.  In particular, the changes from M to v1.1\nare pulled in.  The main change from M to v1.1 is to drop a\nbunch of features.  So by pulling from someone, you lose features\non the master branch.\n\nSo a merge like [*] that drops desirable changes is generally not\na good idea.\n\nCherry-picking to a maintenance branch\n--------------------------------------\n\nAs a result, starting from a history like (1), there is only one\nchoice: cherry-pick only the bugfixes, so the new features are not\nincorporated into the history of the maint branch.\n\n $ git checkout maint\n $ git cherry-pick bugfix1 bugfix2\n\nAfterwards, it is best to merge the maint branch into master, so\nlater changes on the maint branch can be merged into master more\neasily.  Usually despite the duplicate changes will not result in\nconflicts.\n\n $ git checkout master\n $ git merge maint\n $ git diff HEAD^\n $ : looks good\n $ git push public maint master\n\nIf there are conflicts, no need to worry: make sure that \"master\"\nreally includes all desirable changes from maint and merge with\nstrategy ours instead.\n\n $ git reset --merge\n $ git merge -s ours maint\n\nWriting a new bugfix\n--------------------\n\nSuppose you have an idea for a new bugfix.  As discussed above, if\nyou write it directly on top of master, when it is time to apply\nit to maint it will need cherry-picking.  If you base the patch\non maint, you can avoid that:\n\n $ git checkout -b bugfix maint\n ... hack hack hack ...\n $ make test\n $ : looks good\n $ git checkout master\n $ git merge bugfix\n $ make test\n $ git push public bugfix master\n\n v1.1 [maint] --- X [bugfix]\n     \\             \\\n      o --- ... --- N [master]\n\n\nOnce the patch gets enough testing from users of master, it is\ntime to apply it to maint.\n\n $ git checkout maint\n $ git merge bugfix\n $ make test\n $ git checkout master\n $ git merge maint\n $ git push public maint master\n\n v1.1 ----------- X [maint]\n     \\             \\\n      o --- ... --- N [master]\n\nOne benefit of this approach is that during development, the patch\nis tested against the maintenance branch, which is incidentally\nprobably where it is most important that it get testing.\n\nHope that helps,\nJonathan\n"},{"id":"148397","messageId":"AANLkTi=MLE6WEmmDb6964-wX4f79ucpGU6SPieQK66ry@mail.gmail.com","threadId":"24774","inReplyTo":"20100818015947.GA19632@burratino","subject":"Re: Ignoring commits when merging","fromName":"Mike Strauch","fromEmail":"mike.strauch@hannonhill.com","sentAt":"2010-08-18T18:08:20Z","receivedAt":"2010-08-18T18:08:20Z","isPatch":false,"sender":{"key":"mike.strauch@hannonhill.com","avatar":null},"body":"Jonathan,\n\nThanks for the info.  The scenario that I am in is most like the\n\"Writing a new bugfix\" scenario you've described.  We have a\nmaintenance branch in which the majority of commits are bug fixes.  We\nwould then like to merge those bug fixes into our master branch.  The\ndifference being that there will occasionally be a commit in our\nmaintenance branch that we do not want to merge into our master branch\nbecause it contains application version information which is only\nrelevant when we release something out of our maintenance branch.  So,\nthe tree looks like:\n\n              Release\n\n                   |\n       ------- previous bug fixes --------- version info commit----\nv1.0 --- bug fix commits --- X [maint]\n      /                                     \\ M1\n--- o --------- ...\n-------------------------------------------------------------------- N\n[master]\n               \\                                      /\n                -----------...--------- F [new feature branch]\n\nYou'll also notice I've included a new feature branch here to give\nmore of a big picture view of our setup.\n\nSo, what happens is this:\n\n1. We fix some bugs in the maint branch (previous bug fixes)\n2. We test those fixes\n3. Merge the fixes back into master (M1)\n4. Commit version information to maint branch (version info commit)\n5. Release from maint branch (v1.0)\n6. Start the process over from step 1 but with the version information\ncommit in the maint branch commit history.\n\nSo, in this scenario there is really only ever 1 commit that we don't\nwant to be merged into master from the maint branch.  This is not\nalways the case of course.  There could be some other commits in maint\nbranch that we don't want to merge back into master.  Anyway, if you\nhave any more feedback that would be great.  Either way, I'll have to\ntake a look at the man page you suggested.\n\nThanks again,\n\n-Mike\n\nOn Tue, Aug 17, 2010 at 9:59 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> Hi,\n>\n> Mike Strauch wrote:\n>\n>> I'm fairly new to git and I'm trying to figure out the best way to\n>> ignore certain commits when merging one branch into another.\n>\n> An interesting question.  The answer (as so often) depends on what\n> you want to do.  \"man 7 gitworkflows\" might help.\n>\n> Below I will pretend you are trying to backport some changes to a more\n> stable branch; others may chime in with other scenarios.\n>\n> First, a general hint: when using git and similar systems, it is\n> generally best if each merged result is somehow \"better\" than all of\n> its parents.  I will give an example below of what can go wrong if\n> this invariant is violated.\n>\n> Merging to a maintenance branch\n> -------------------------------\n>\n> Suppose given a history like this (1):\n>\n>  o --- v1.0 [maint]\n>           \\\n>            feature --- feature --- bugfix --- bugfix [master]\n>\n> Development has been happening on the \"master\" branch and now you\n> want to merge back the relevant fixes to make a new point release,\n> something like the following:\n>\n> [*] o --- v1.0 ------------------------------------ v1.1 [maint]\n>              \\                                    /\n>               master-only feature --- bugfix --- M [master]\n>\n>  \"a dangerous history\"\n>\n> Let's consider what that would mean.  Someone builds some new\n> work off of maint:\n>\n>  o --- v1.0 --- v1.1 --- o ... o --- A [someone]\n>               /\n>\n> What happens when you pull the \"someone\" branch into master?  The\n> relevant piece of history looks like this:\n>\n>        v1.1 --- o ... o --- A [someone]\n>       /\n>  ... M --- new development --- ... --- B [master]\n>\n> When you try to pull A into B, git runs a three-way merge to\n> apply the changes from the someone branch after the branch point (M)\n> on the master branch.  In particular, the changes from M to v1.1\n> are pulled in.  The main change from M to v1.1 is to drop a\n> bunch of features.  So by pulling from someone, you lose features\n> on the master branch.\n>\n> So a merge like [*] that drops desirable changes is generally not\n> a good idea.\n>\n> Cherry-picking to a maintenance branch\n> --------------------------------------\n>\n> As a result, starting from a history like (1), there is only one\n> choice: cherry-pick only the bugfixes, so the new features are not\n> incorporated into the history of the maint branch.\n>\n>  $ git checkout maint\n>  $ git cherry-pick bugfix1 bugfix2\n>\n> Afterwards, it is best to merge the maint branch into master, so\n> later changes on the maint branch can be merged into master more\n> easily.  Usually despite the duplicate changes will not result in\n> conflicts.\n>\n>  $ git checkout master\n>  $ git merge maint\n>  $ git diff HEAD^\n>  $ : looks good\n>  $ git push public maint master\n>\n> If there are conflicts, no need to worry: make sure that \"master\"\n> really includes all desirable changes from maint and merge with\n> strategy ours instead.\n>\n>  $ git reset --merge\n>  $ git merge -s ours maint\n>\n> Writing a new bugfix\n> --------------------\n>\n> Suppose you have an idea for a new bugfix.  As discussed above, if\n> you write it directly on top of master, when it is time to apply\n> it to maint it will need cherry-picking.  If you base the patch\n> on maint, you can avoid that:\n>\n>  $ git checkout -b bugfix maint\n>  ... hack hack hack ...\n>  $ make test\n>  $ : looks good\n>  $ git checkout master\n>  $ git merge bugfix\n>  $ make test\n>  $ git push public bugfix master\n>\n>  v1.1 [maint] --- X [bugfix]\n>     \\             \\\n>      o --- ... --- N [master]\n>\n>\n> Once the patch gets enough testing from users of master, it is\n> time to apply it to maint.\n>\n>  $ git checkout maint\n>  $ git merge bugfix\n>  $ make test\n>  $ git checkout master\n>  $ git merge maint\n>  $ git push public maint master\n>\n>  v1.1 ----------- X [maint]\n>     \\             \\\n>      o --- ... --- N [master]\n>\n> One benefit of this approach is that during development, the patch\n> is tested against the maintenance branch, which is incidentally\n> probably where it is most important that it get testing.\n>\n> Hope that helps,\n> Jonathan\n>\n"},{"id":"148426","messageId":"20100818233809.GF2346@burratino","threadId":"24774","inReplyTo":"AANLkTi=MLE6WEmmDb6964-wX4f79ucpGU6SPieQK66ry@mail.gmail.com","subject":"Re: Ignoring commits when merging","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-18T23:38:09Z","receivedAt":"2010-08-18T23:38:09Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Mike Strauch wrote:\n\n> We have a\n> maintenance branch in which the majority of commits are bug fixes.  We\n> would then like to merge those bug fixes into our master branch.  The\n> difference being that there will occasionally be a commit in our\n> maintenance branch that we do not want to merge into our master branch\n> because it contains application version information\n\nI see.  Yes, this is interesting (and not covered by gitworkflows though\nit should be).\n\n> 1. We fix some bugs in the maint branch (previous bug fixes)\n> 2. We test those fixes\n> 3. Merge the fixes back into master (M1)\n> 4. Commit version information to maint branch (version info commit)\n> 5. Release from maint branch (v1.0)\n> 6. Start the process over from step 1 but with the version information\n> commit in the maint branch commit history.\n> \n> So, in this scenario there is really only ever 1 commit that we don't\n> want to be merged into master from the maint branch.\n\nNow your \"merge -s ours\" solution is looking like a good one.  So the\nworkflow on the release day might look like this:\n\n 1. Fix some bugs on maint\n 2. Test them\n 3. Merge fixes back into master\n 4. Version info commit on the maint branch\n 5. Test a little more, tag the release.\n 6. \"merge -s ours\" from maint to master\n 7. Do some other work on topic branches and master.\n 8. Push.\n\nIdeally, in the published history, maint would _always_ be an ancestor\nof master.  Life is simpler that way.\n\n> This is not\n> always the case of course.  There could be some other commits in maint\n> branch that we don't want to merge back into master.\n\nSure.  Another possibility is to explicitly revert patches from maint,\neither as a separate commit or as part of a merge.  The latter would\ngenerally not make sense unless it is a very small patch.\n\nFor example:\n\n 1. Fix some bugs on maint.\n 2. Notice a test on maint is passing now.  Mark it as such.\n 3. ... more work on maint ...\n 4. Switch to master.  Merge from maint.  Since the test is\n    failing:\n    i.   \"git reset --keep HEAD^\" (undo the merge)\n    ii.  \"git merge --no-commit maint\"\n    iii. Mark the test as expected to fail.\n    iv.  \"git commit\", mentioning the test failure in the log message.\n\nThis is called an \"evil merge\" because it introduces changes that\nare not from either side.  Used judiciously it can be useful for\nensuring that every commit passes some basic tests (which might be\nwanted if you use \"git bisect\" heavily).\n\n\"git revert\" is simpler, of course.\n\nHope that helps.\nJonathan\n"}]}