{"thread":{"id":"17161","subject":"git merge and cherry-pick and duplicated commits?","startedAt":"2009-01-14T02:40:53Z","lastAt":"2009-01-15T23:09:10Z","messageCount":16,"participants":["skillzero@gmail.com","Brian Gernhardt","Johannes Sixt","Nanako Shiraishi","Boaz Harrosh","Thomas Rast","Alex Riesen","Sitaram Chamarty","Peter Baumann","Junio C Hamano","Markus Heidelberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"100356","messageId":"2729632a0901131840v5c7ce0c7l3f87c03caabf68de@mail.gmail.com","threadId":"17161","inReplyTo":null,"subject":"git merge and cherry-pick and duplicated commits?","fromName":"","fromEmail":"skillzero@gmail.com","sentAt":"2009-01-14T02:40:53Z","receivedAt":"2009-01-14T02:40:53Z","isPatch":false,"sender":{"key":"skillzero@gmail.com","avatar":null},"body":"I created a branch from master, did a commit (8e9fdd), then did 2 more\ncommits (11c59c and 7024d), then did another commit (2daf23). From\nmaster, I did a commit (47bd1b) then cherry-pick'd 2 commits from the\nbranch (11c59c and 7024d). When merged the branch into master, I see\nthe 2 cherry-picked commits twice in the log (once from the original\ncherry-pick's and again from the merge).\n\nI thought git would realize that master already had those 2 commits\nand not add them again when merging?\n"},{"id":"100364","messageId":"5EA96780-EF4C-4B31-9C60-6ABAF21663FA@silverinsanity.com","threadId":"17161","inReplyTo":"2729632a0901131840v5c7ce0c7l3f87c03caabf68de@mail.gmail.com","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2009-01-14T05:31:22Z","receivedAt":"2009-01-14T05:31:22Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"On Jan 13, 2009, at 9:40 PM, skillzero@gmail.com wrote:\n\n> I created a branch from master, did a commit (8e9fdd), then did 2 more\n> commits (11c59c and 7024d), then did another commit (2daf23). From\n> master, I did a commit (47bd1b) then cherry-pick'd 2 commits from the\n> branch (11c59c and 7024d). When merged the branch into master, I see\n> the 2 cherry-picked commits twice in the log (once from the original\n> cherry-pick's and again from the merge).\n\nBefore the cherry-picks, your repository looks like this\n\no-o (master: 47bd1b)\n \\\n o-A-B-o (branch:2daf23)\n\nA and B are the two commits you cherry-picked (11c59c and 7024d)\n\nAfter the cherry-picks, the repo looks like this:\n\no-o-A'-B' (master)\n \\\n o-A-B-o (branch:2daf23)\n\nA and A' are different commits. Same with B and B'. If you check the \nSHA1 of master at this point, it will NOT be 702fd... (B). Cherry \npick creates a new commit that (as far as git is concerned) is totally \nunrelated.\n\nAfter the merge, you get:\n\no-o-A'-B'-o (master)\n \\ /\n o-A-B-o\n\nSince git has no knowledge that the cherry-picked (A' B') commits are \nrelated to their originals (A B), it displays both to you. If you \nwant, you can use the -x flag when you use \"git cherry-pick\" to add a \nline that describes the original source of the patch in the new commit \nwhich eases confusion when you look at the history, but will not stop \nthem from being displayed.\n\n(The reason git will still display them is that the cherry-picked \ncommits may be different if there were conflicting changes on the \nbranches. Also, hiding those commits would give a false view of \nhistory since the changes were actually added to the repository \ntwice. Using gitk or \"git log --graph\" will show the commits on two \ndifferent lines of development.)\n\n> I thought git would realize that master already had those 2 commits\n> and not add them again when merging?\n\nThe simplest method is to rebase branch after doing the cherry-picks. \nThis should only be done if your branch has not been published. From \nafter the cherry-picks:\n\no-o-A'-B' (master)\n \\\n o-A-B-o (branch:2daf23)\n\n\"git rebase master branch\" would give you\n\no-o-A'-B' (master)\n \\\n o'-o' (branch)\n\nGit should detect that the changes from A and B were already present \nin master during the rebase and skip the commits.\n\n~~ Brian Gernhardt\n"},{"id":"100367","messageId":"2729632a0901132221r746144a1y9628615be1c6ad04@mail.gmail.com","threadId":"17161","inReplyTo":"5EA96780-EF4C-4B31-9C60-6ABAF21663FA@silverinsanity.com","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"","fromEmail":"skillzero@gmail.com","sentAt":"2009-01-14T06:21:23Z","receivedAt":"2009-01-14T06:21:23Z","isPatch":false,"sender":{"key":"skillzero@gmail.com","avatar":null},"body":"On Tue, Jan 13, 2009 at 9:31 PM, Brian Gernhardt\n wrote:\n\n> After the cherry-picks, the repo looks like this:\n>\n> o-o-A'-B' (master)\n> \\\n> o-A-B-o (branch:2daf23)\n>\n> A and A' are different commits. Same with B and B'. If you check the SHA1\n> of master at this point, it will NOT be 702fd... (B). Cherry pick creates a\n> new commit that (as far as git is concerned) is totally unrelated.\n\nThat's what I was somewhat disappointed by. Even though the result of\nthe commit had a different hash, I assumed git would keep some kind of\ninternal per-commit hash so it could tell later that two commits were\nthe same and not re-apply them.\n\n> The simplest method is to rebase branch after doing the cherry-picks. This\n> should only be done if your branch has not been published.\n\nThe problem is, by the time I wanted to do the cherry-pick, I had\nalready committed other stuff to the branch. I tried doing 'git rebase\nmaster branch' when on master and it just applied all the stuff from\nmaster to branch.\n\nIs there any way to apply a commit to 2 different branches (which have\ndiverged) in a way that git will remember so that when the 2 branches\nmerge later, it won't result in duplicate commits? I find that I often\nmake changes that days or weeks later find out that some other branch\nneeds that change and by then, there have been lots of commits to both\nbranches after the commit I want.\n"},{"id":"100374","messageId":"2729632a0901132333h6caf9facu871869abce5597c1@mail.gmail.com","threadId":"17161","inReplyTo":"5EA96780-EF4C-4B31-9C60-6ABAF21663FA@silverinsanity.com","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"","fromEmail":"skillzero@gmail.com","sentAt":"2009-01-14T07:33:23Z","receivedAt":"2009-01-14T07:33:23Z","isPatch":false,"sender":{"key":"skillzero@gmail.com","avatar":null},"body":"I guess maybe a better question is how do people normally handle\nsituations like mine where I did some work on branch X and I later\nrealize I need only a portion of that work on branch Y? I'm not sure\nhow I can change my workflow to completely eliminate these situations.\nFor example, I often start a branch to add a new feature and I end up\nfixing bug A on that branch. Then other people on my team decide they\nneed the fix for bug A immediately and can't wait for me to finish my\nfeature branch and do a full merge.\n\nIs there some way I can change my workflow such that I can fix bug A\n(maybe on a separate branch?) and somehow apply it to both both\nbranches in a way that won't result in duplicate commits?\n\nDoes this kind of thing ever happen with the Linux kernel or git\nitself: somebody does a fix as part of their topic branch and the\nLinux kernel or git master wants that particular fix now, but is not\nready for the full topic branch? Would they just suggest the fix be\nseparated into its own topic branch and that merged? If so, how would\nthat new topic branch merge into the original topic branch without\nresulting in a duplicate commit when it's later merged into master?\n"},{"id":"100375","messageId":"496D9572.2090303@viscovery.net","threadId":"17161","inReplyTo":"2729632a0901132221r746144a1y9628615be1c6ad04@mail.gmail.com","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-01-14T07:34:10Z","receivedAt":"2009-01-14T07:34:10Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"skillzero@gmail.com schrieb:\n> Is there any way to apply a commit to 2 different branches (which have\n> diverged) in a way that git will remember so that when the 2 branches\n> merge later, it won't result in duplicate commits? I find that I often\n> make changes that days or weeks later find out that some other branch\n> needs that change and by then, there have been lots of commits to both\n> branches after the commit I want.\n\nWell, the way to do it is \"careful planning\".\n\nIf you have a *slight* suspicion that some change *might* be needed on a\ndifferent branch, then:\n\n1. you commit the change on a branch of its own that forks off of the\nmerge-base of *all* the branches that *might* need it;\n\n2. next, you merge this fix-up branch into the branch where you need it\nfirst, which is very likely your current topic-under-development.\n\n3. Later you can merge the branch into the other branches if you find that\nit is really needed.\n\nIf you don't have the slight suspicion, then you have to take the\nsecond-best route, namely to cherry-pick the commit onto a branch just\nlike in 1. above, and continue with 2. and 3. In this case you have the\ncommit twice, but not more than that.\n\n-- Hannes\n"},{"id":"100378","messageId":"2729632a0901140008r59e429aeq3ce367e1bc7df71@mail.gmail.com","threadId":"17161","inReplyTo":"496D9572.2090303@viscovery.net","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"","fromEmail":"skillzero@gmail.com","sentAt":"2009-01-14T08:08:06Z","receivedAt":"2009-01-14T08:08:06Z","isPatch":false,"sender":{"key":"skillzero@gmail.com","avatar":null},"body":"On Tue, Jan 13, 2009 at 11:34 PM, Johannes Sixt wrote:\n\n> Well, the way to do it is \"careful planning\".\n>\n> If you have a *slight* suspicion that some change *might* be needed on a\n> different branch, then:\n>\n> 1. you commit the change on a branch of its own that forks off of the\n> merge-base of *all* the branches that *might* need it;\n>\n> 2. next, you merge this fix-up branch into the branch where you need it\n> first, which is very likely your current topic-under-development.\n>\n> 3. Later you can merge the branch into the other branches if you find that\n> it is really needed.\n\nIf I create a separate bug-fix-only branch X that forks from the\nlatest common commit of all the branches that might need it and some\nof those branches already have commits after that merge base (e.g.\nbranch Z is 5 commits after the common merge base by the time I fix\nthe bug), will git be able to merge the new branch X into Z in a way\nthat will allow me to also merge branch X into my original feature\nbranch A and then later merge A into Z without duplicating the commit\nthat is now in both branch X and Z?\n\nIt seems like I'd run into my original duplicate commit problem\nbecause even though branch X was originally based off the same parent\ncommit, it will have a different parent when it is merged into Z\nbecause Z is no longer at that common merge commit (it's 5 commits\nbeyond it).\n"},{"id":"100380","messageId":"20090114173140.6117@nanako3.lavabit.com","threadId":"17161","inReplyTo":"2729632a0901132221r746144a1y9628615be1c6ad04@mail.gmail.com","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-01-14T08:31:40Z","receivedAt":"2009-01-14T08:31:40Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting skillzero@gmail.com:\n\n> The problem is, by the time I wanted to do the cherry-pick, I had\n> already committed other stuff to the branch. I tried doing 'git rebase\n> master branch' when on master and it just applied all the stuff from\n> master to branch.\n>\n> Is there any way to apply a commit to 2 different branches (which have\n> diverged) in a way that git will remember so that when the 2 branches\n> merge later, it won't result in duplicate commits? I find that I often\n> make changes that days or weeks later find out that some other branch\n> needs that change and by then, there have been lots of commits to both\n> branches after the commit I want.\n\nJohennes Sixt gave a good answer. You need to think before making your commits while you are developing to separate what change belongs to common code base and what change belongs to a specific feature.\n\nI was reading gitster's blog (he has several \"git tutorial\" articles recently) and he talks about how to commit a change to a branch different from what you originally developed it on in today's entry. You may find it instructive, but the procedure is after you think about it and decide what change goes where.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"100382","messageId":"496DA3B2.1070807@viscovery.net","threadId":"17161","inReplyTo":"2729632a0901140008r59e429aeq3ce367e1bc7df71@mail.gmail.com","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-01-14T08:34:58Z","receivedAt":"2009-01-14T08:34:58Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"[Please reply-to-all on this list, to keep Cc: list]\n\nskillzero@gmail.com schrieb:\n> On Tue, Jan 13, 2009 at 11:34 PM, Johannes Sixt wrote:\n> \n>> Well, the way to do it is \"careful planning\".\n>>\n>> If you have a *slight* suspicion that some change *might* be needed on a\n>> different branch, then:\n>>\n>> 1. you commit the change on a branch of its own that forks off of the\n>> merge-base of *all* the branches that *might* need it;\n>>\n>> 2. next, you merge this fix-up branch into the branch where you need it\n>> first, which is very likely your current topic-under-development.\n>>\n>> 3. Later you can merge the branch into the other branches if you find that\n>> it is really needed.\n> \n> If I create a separate bug-fix-only branch X that forks from the\n> latest common commit of all the branches that might need it and some\n> of those branches already have commits after that merge base (e.g.\n> branch Z is 5 commits after the common merge base by the time I fix\n> the bug), will git be able to merge the new branch X into Z in a way\n> that will allow me to also merge branch X into my original feature\n> branch A and then later merge A into Z without duplicating the commit\n> that is now in both branch X and Z?\n> \n> It seems like I'd run into my original duplicate commit problem\n> because even though branch X was originally based off the same parent\n> commit, it will have a different parent when it is merged into Z\n> because Z is no longer at that common merge commit (it's 5 commits\n> beyond it).\n\nAfter you created the fixup, you have this situation:\n\n o--o--o <- A (feature branch)\n /\n--o--x <- X (the fix-up branch)\n \\\n o--o--o <- Z (probably your master)\n\nYou merge the fix-up into the feature branch and continue developing the\nfeature:\n\n o--o--o--M--o--o <- A\n / /\n--o--x-----' <- X\n \\\n o--o--o <- Z\n\nOther people need the fix in Z right now, so you merge it into Z as well:\n\n o--o--o--M--o--o <- A\n / /\n--o--x-----< <- X\n \\ \\\n o--o--o--N <- Z\n\nYou complete your feature and merge it into Z:\n\n o--o--o--M--o--o <- A\n / / \\\n--o--x-----< \\ <- X\n \\ \\ \\\n o--o--o--N---------O <- Z\n\nThe fix-up commit is only once in your history.\n\n-- Hannes\n"},{"id":"100383","messageId":"496DA490.5020708@panasas.com","threadId":"17161","inReplyTo":"2729632a0901140008r59e429aeq3ce367e1bc7df71@mail.gmail.com","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"Boaz Harrosh","fromEmail":"bharrosh@panasas.com","sentAt":"2009-01-14T08:38:40Z","receivedAt":"2009-01-14T08:38:40Z","isPatch":false,"sender":{"key":"bharrosh@panasas.com","avatar":"https://gravatar.com/avatar/347e426f8ca0409f6891ceeefd4c3c2d8769608382323057efeaa362b4c3dbf3?d=mp&s=160"},"body":"skillzero@gmail.com wrote:\n> On Tue, Jan 13, 2009 at 11:34 PM, Johannes Sixt wrote:\n> \n>> Well, the way to do it is \"careful planning\".\n>>\n>> If you have a *slight* suspicion that some change *might* be needed on a\n>> different branch, then:\n>>\n>> 1. you commit the change on a branch of its own that forks off of the\n>> merge-base of *all* the branches that *might* need it;\n>>\n>> 2. next, you merge this fix-up branch into the branch where you need it\n>> first, which is very likely your current topic-under-development.\n>>\n>> 3. Later you can merge the branch into the other branches if you find that\n>> it is really needed.\n> \n> If I create a separate bug-fix-only branch X that forks from the\n> latest common commit of all the branches that might need it and some\n> of those branches already have commits after that merge base (e.g.\n> branch Z is 5 commits after the common merge base by the time I fix\n> the bug), will git be able to merge the new branch X into Z in a way\n> that will allow me to also merge branch X into my original feature\n> branch A and then later merge A into Z without duplicating the commit\n> that is now in both branch X and Z?\n> \n> It seems like I'd run into my original duplicate commit problem\n> because even though branch X was originally based off the same parent\n> commit, it will have a different parent when it is merged into Z\n> because Z is no longer at that common merge commit (it's 5 commits\n> beyond it).\n> --\n\nNo, if you use merges it will not duplicate. It will know exactly what\nto do because it is the same commit in all branches.\nOnly git-cherry-pick will duplicate the same patch, but as a different\nnew commit. Then when merging the merge sees a merge conflict but since\nit is exactly the same change it will accept it. The same happens if\ntwo different patches have exact same hunk, the merge is smart to accept\nthe same change from two sources. What happen with cherry-pick is that all\nthe hunks match.\n\nBoaz\n"},{"id":"100384","messageId":"200901140941.17110.trast@student.ethz.ch","threadId":"17161","inReplyTo":"2729632a0901132221r746144a1y9628615be1c6ad04@mail.gmail.com","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-01-14T08:41:14Z","receivedAt":"2009-01-14T08:41:14Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"skillzero@gmail.com wrote:\n> I thought git would realize that master already had those 2 commits\n> and not add them again when merging?\n\n[later]\n> That's what I was somewhat disappointed by. Even though the result of\n> the commit had a different hash, I assumed git would keep some kind of\n> internal per-commit hash so it could tell later that two commits were\n> the same and not re-apply them.\n\nI think there's an important misunderstanding here: merging A into B\ndoes *not* have anything to do with commits, or history for that\nmatter, beyond the differences from $(git merge-base A B) to A and\nB.[*]\n\nAlong the same lines, nothing is ever re-applied during merging.\ngit-merge just figures out that you made the same change on both\nsides, so it must have been a good change, so it must go into the end\nresult. *How* you arrived at the same change---say, by\ncherry-picking, or by getting the same result in that region from\notherwise different commits, or even from several commits---does *not*\nmatter in any way.\n\nYou can use 'git cherry', 'git log --left-right --cherry-pick', and\nsimilar tools to find commits that are cherry-picked \"duplicates\", but\nunless you rewrite history, they are there to stay.\n\n\n[*] This is a simplification since as soon as the merge-base is not\nunique, merge-recursive will actually start looking into history\nfurther back.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n\n\n"},{"id":"100407","messageId":"81b0412b0901140547u2fbd2feh89fc80f64b9bab81@mail.gmail.com","threadId":"17161","inReplyTo":"200901140941.17110.trast@student.ethz.ch","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-01-14T13:47:03Z","receivedAt":"2009-01-14T13:47:03Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"2009/1/14 Thomas Rast :\n> skillzero@gmail.com wrote:\n>> That's what I was somewhat disappointed by. Even though the result of\n>> the commit had a different hash, I assumed git would keep some kind of\n>> internal per-commit hash so it could tell later that two commits were\n>> the same and not re-apply them.\n>\n> I think there's an important misunderstanding here: merging A into B\n> does *not* have anything to do with commits, or history for that\n> matter, beyond the differences from $(git merge-base A B) to A and\n> B.[*]\n>\n> Along the same lines, nothing is ever re-applied during merging.\n> git-merge just figures out that you made the same change on both\n> sides, so it must have been a good change, so it must go into the end\n> result. *How* you arrived at the same change---say, by\n> cherry-picking, or by getting the same result in that region from\n> otherwise different commits, or even from several commits---does *not*\n> matter in any way.\n\nYes, merge only considers what bytes (aka contents of\ntrees-directories and blobs-files) do the branches to be merged\nhave, compares them (by comparing their hashes) and if there\nare differences tries to mix them together according to the merge\nrules described somewhere in Documentation.\n\nSo this all is really just about what the branches contain, not\nhow they got it. It is the conflict resolution algorithm which uses\nthe history to find the best possible source blob or tree which was\nchanged by conflicting branches so the \"mix\" can be prepared as\nclose as possible to what would we do if we went looking for the\npieces manually.\n"},{"id":"100425","messageId":"slrngms2k7.s3e.sitaramc@sitaramc.homelinux.net","threadId":"17161","inReplyTo":"2729632a0901132333h6caf9facu871869abce5597c1@mail.gmail.com","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-01-14T15:53:43Z","receivedAt":"2009-01-14T15:53:43Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-01-14, skillzero@gmail.com wrote:\n> I guess maybe a better question is how do people normally handle\n> situations like mine where I did some work on branch X and I later\n> realize I need only a portion of that work on branch Y? I'm not sure\n> how I can change my workflow to completely eliminate these situations.\n> For example, I often start a branch to add a new feature and I end up\n> fixing bug A on that branch. Then other people on my team decide they\n> need the fix for bug A immediately and can't wait for me to finish my\n> feature branch and do a full merge.\n>\n> Is there some way I can change my workflow such that I can fix bug A\n> (maybe on a separate branch?) and somehow apply it to both both\n> branches in a way that won't result in duplicate commits?\n>\n> Does this kind of thing ever happen with the Linux kernel or git\n> itself: somebody does a fix as part of their topic branch and the\n> Linux kernel or git master wants that particular fix now, but is not\n> ready for the full topic branch? Would they just suggest the fix be\n> separated into its own topic branch and that merged? If so, how would\n> that new topic branch merge into the original topic branch without\n> resulting in a duplicate commit when it's later merged into master?\n\nIf I understand you right, you're talking about a situation\nwhere a particular change is in two different branches, but\nthe SHA is different.\n\nAnd yet, in your scenario, both of these branches somehow\nget merged into the final branch.\n\nIn other words, a DAG of branches merging itself has a\nmerge, if that makes sense :-)\n\nYou may need to think about how commits flow from branch to\nbranch, and what branches are private, and therefore can be\nrebased or change history, and what are public, and how\noften and when the private ones rebase off of the public\nones.\n"},{"id":"100457","messageId":"2729632a0901141033p47b4d8dah46f5bac27307d306@mail.gmail.com","threadId":"17161","inReplyTo":"496DA3B2.1070807@viscovery.net","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"","fromEmail":"skillzero@gmail.com","sentAt":"2009-01-14T18:33:02Z","receivedAt":"2009-01-14T18:33:02Z","isPatch":false,"sender":{"key":"skillzero@gmail.com","avatar":null},"body":"On Wed, Jan 14, 2009 at 12:34 AM, Johannes Sixt wrote:\n\n> After you created the fixup, you have this situation:\n>\n> o--o--o <- A (feature branch)\n> /\n> --o--x <- X (the fix-up branch)\n> \\\n> o--o--o <- Z (probably your master)\n>\n> You merge the fix-up into the feature branch and continue developing the\n> feature:\n>\n> o--o--o--M--o--o <- A\n> / /\n> --o--x-----' <- X\n> \\\n> o--o--o <- Z\n>\n> Other people need the fix in Z right now, so you merge it into Z as well:\n>\n> o--o--o--M--o--o <- A\n> / /\n> --o--x-----< <- X\n> \\ \\\n> o--o--o--N <- Z\n>\n> You complete your feature and merge it into Z:\n>\n> o--o--o--M--o--o <- A\n> / / \\\n> --o--x-----< \\ <- X\n> \\ \\ \\\n> o--o--o--N---------O <- Z\n>\n> The fix-up commit is only once in your history.\n\nThanks for the info. That's what I was hoping, but I was thinking that\nI'd get duplicate commits if I did that. I'll have to try it out when\nI run into this situation again.\n\nRelated to this, is there a way to easily find the common merge base\ngiven a bunch of a branches? When I want to fix a bug, I want to say\n\"Given branches A, B, C, D, and E, where should I fork my bug fix\nbranch from so that I can merge this branch into all those branches\nwithout getting duplicate commits?\".\n"},{"id":"100466","messageId":"20090114194042.GB15129@m62s10.vlinux.de","threadId":"17161","inReplyTo":"2729632a0901141033p47b4d8dah46f5bac27307d306@mail.gmail.com","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2009-01-14T19:40:42Z","receivedAt":"2009-01-14T19:40:42Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Wed, Jan 14, 2009 at 10:33:02AM -0800, skillzero@gmail.com wrote:\n> On Wed, Jan 14, 2009 at 12:34 AM, Johannes Sixt \n> wrote:\n> \n[ ... ]\n \n> Related to this, is there a way to easily find the common merge base\n> given a bunch of a branches? When I want to fix a bug, I want to say\n> \"Given branches A, B, C, D, and E, where should I fork my bug fix\n> branch from so that I can merge this branch into all those branches\n> without getting duplicate commits?\".\n\nYou should have a look at 'git help merge-base'\n\n-Peter\n"},{"id":"100476","messageId":"7v4p011w3r.fsf@gitster.siamese.dyndns.org","threadId":"17161","inReplyTo":"2729632a0901141033p47b4d8dah46f5bac27307d306@mail.gmail.com","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-14T20:16:56Z","receivedAt":"2009-01-14T20:16:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"skillzero@gmail.com writes:\n\n> Related to this, is there a way to easily find the common merge base\n> given a bunch of a branches? When I want to fix a bug, I want to say\n> \"Given branches A, B, C, D, and E, where should I fork my bug fix\n> branch from so that I can merge this branch into all those branches\n> without getting duplicate commits?\".\n\nYou do not necessarily have to fork from, nor merge into, any of them.\n\nIf you fixed a bug, you would hopefully know where the bug was injected at\ninto your history. You may have bisected it down to one commit $BAD. You\ncan fork your fix on top of that $BAD commit:\n\n\t$ git checkout -b fix-bug-foo $BAD\n\nAll of the branches that share the commit have the bug, so your fix could\nbe merged to all of them if you really wanted to, and you should do so if\nthese A...E branches are meant to be consumed on their own.\n\nBut if the branches A...E you are about are for developing independent\ntopics, and if their theme won't get affected by the bug, it is much\nbetter not to merge the fix in. You will have the merge for the fix in\nyour integration branch anyway. It is preferable not to contaminate an\nindependent topic branch whose purpose is to cook its own theme with an\nunrelated bugfix, even if it is brought in as a merge.\n"},{"id":"100672","messageId":"200901160009.11124.markus.heidelberg@web.de","threadId":"17161","inReplyTo":"2729632a0901141033p47b4d8dah46f5bac27307d306@mail.gmail.com","subject":"Re: git merge and cherry-pick and duplicated commits?","fromName":"Markus Heidelberg","fromEmail":"markus.heidelberg@web.de","sentAt":"2009-01-15T23:09:10Z","receivedAt":"2009-01-15T23:09:10Z","isPatch":false,"sender":{"key":"markus.heidelberg@web.de","avatar":"https://avatars.githubusercontent.com/u/6334512?v=4"},"body":"skillzero@gmail.com, 14.01.2009:\n> On Wed, Jan 14, 2009 at 12:34 AM, Johannes Sixt wrote:\n> \n> > After you created the fixup, you have this situation:\n> >\n> > o--o--o <- A (feature branch)\n> > /\n> > --o--x <- X (the fix-up branch)\n> > \\\n> > o--o--o <- Z (probably your master)\n> >\n> > You merge the fix-up into the feature branch and continue developing the\n> > feature:\n> >\n> > o--o--o--M--o--o <- A\n> > / /\n> > --o--x-----' <- X\n> > \\\n> > o--o--o <- Z\n> >\n> > Other people need the fix in Z right now, so you merge it into Z as well:\n> >\n> > o--o--o--M--o--o <- A\n> > / /\n> > --o--x-----< <- X\n> > \\ \\\n> > o--o--o--N <- Z\n> >\n> > You complete your feature and merge it into Z:\n> >\n> > o--o--o--M--o--o <- A\n> > / / \\\n> > --o--x-----< \\ <- X\n> > \\ \\ \\\n> > o--o--o--N---------O <- Z\n> >\n> > The fix-up commit is only once in your history.\n> \n> Thanks for the info. That's what I was hoping, but I was thinking that\n> I'd get duplicate commits if I did that. I'll have to try it out when\n> I run into this situation again.\n\nNote, that you'd get 2 merge commits for this fix-up commit into branch Z.\nThe first from merging X into Z, the second is created from merging X\ninto A and occures in Z when merging A into it.\n\nMarkus\n"}]}