{"thread":{"id":"7756","subject":"cherry-pick --since ?","startedAt":"2007-04-20T16:20:32Z","lastAt":"2009-07-17T08:41:37Z","messageCount":12,"participants":["Brandon Casey","Alex Riesen","Junio C Hamano","David Kågedal","bshOriginal","Michael J Gruber","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39990","messageId":"Pine.LNX.4.64.0704201100050.4667@torch.nrlssc.navy.mil","threadId":"7756","inReplyTo":null,"subject":"cherry-pick --since ?","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2007-04-20T16:20:32Z","receivedAt":"2007-04-20T16:20:32Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"\n\nIs there functionality to allow something akin to\na\n git cherry-pick --since \n\nor maybe syntax similar to git cherry where the upstream, head,\nand limit can be specified. Or the .. syntax would work.\n\n\nHere's my use case:\n\nTwo branches, 'A' and 'B'.\n'A' is the master branch.\n'B' was forked some time ago and is in bug fix only mode.\nMuch of 'A' and 'B' are still the same, but there have been\n some intrusive changes made to 'A' that should not go into 'B'.\n This is also why I can't just pull from 'B'. rebase may work,\n but then of course all of the commit id's change.\n\nWhen changes are made in 'B' I currently cherry-pick each commit\ninto 'A' (where possible). This can be tedious when there are many\ncommits. I can use git cherry to show me which commits should be\ncherry-picked, it would be nice if I could cherry-pick a range of\ncommits.\n\nI am not subscribed to the list so please cc me. I hope this is ok,\nif not let me know and I will subscribe. I am only a casual read of\nthe list.\n\n-brandon\n"},{"id":"40000","messageId":"20070420185524.GA4420@steel.home","threadId":"7756","inReplyTo":"Pine.LNX.4.64.0704201100050.4667@torch.nrlssc.navy.mil","subject":"Re: cherry-pick --since ?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-20T18:55:24Z","receivedAt":"2007-04-20T18:55:24Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Brandon Casey, Fri, Apr 20, 2007 18:20:32 +0200:\n> Is there functionality to allow something akin to a\n>\n> git cherry-pick --since \n> \n\ngit format-patch --stdin --binary --full-index -k from..to | git am -k -3\n"},{"id":"40012","messageId":"7v647qy7dn.fsf@assigned-by-dhcp.cox.net","threadId":"7756","inReplyTo":"Pine.LNX.4.64.0704201100050.4667@torch.nrlssc.navy.mil","subject":"Re: cherry-pick --since ?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-20T23:05:08Z","receivedAt":"2007-04-20T23:05:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Casey writes:\n\n> Is there functionality to allow something akin to\n> a\n> git cherry-pick --since \n>\n> or maybe syntax similar to git cherry where the upstream, head,\n> and limit can be specified. Or the .. syntax would work.\n>\n>\n> Here's my use case:\n>\n> Two branches, 'A' and 'B'.\n> 'A' is the master branch.\n> 'B' was forked some time ago and is in bug fix only mode.\n> Much of 'A' and 'B' are still the same, but there have been\n> some intrusive changes made to 'A' that should not go into 'B'.\n\nYou forgot to say \"My objective is to make sure all the good\nfixes in B are forward ported to A\" but I am assuming that is\nthe case.\n\n> This is also why I can't just pull from 'B'. rebase may work,\n> but then of course all of the commit id's change.\n\nI do not understand why you cannot merge 'B' into 'A'. From the\ncommit ancestry perspective, merging is exactly the right thing\nto do if your goal is to forward port all fixes in B to A.\n"},{"id":"40112","messageId":"87slasr4te.fsf@morpheus.local","threadId":"7756","inReplyTo":"20070420185524.GA4420@steel.home","subject":"Re: cherry-pick --since ?","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-04-22T12:06:53Z","receivedAt":"2007-04-22T12:06:53Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Alex Riesen writes:\n\n> Brandon Casey, Fri, Apr 20, 2007 18:20:32 +0200:\n>> Is there functionality to allow something akin to a\n>>\n>> git cherry-pick --since \n>> \n>\n> git format-patch --stdin --binary --full-index -k from..to | git am -k -3\n\nI guess you meant --stdout rather than --stdin here.\n\n-- \nDavid Kågedal\n"},{"id":"40222","messageId":"Pine.LNX.4.64.0704231208490.4667@torch.nrlssc.navy.mil","threadId":"7756","inReplyTo":"7v647qy7dn.fsf@assigned-by-dhcp.cox.net","subject":"Re: cherry-pick --since ?","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2007-04-23T17:52:35Z","receivedAt":"2007-04-23T17:52:35Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"On Fri, 20 Apr 2007, Junio C Hamano wrote:\n> Brandon Casey writes:\n>\n>> Is there functionality to allow something akin to\n>> a\n>> git cherry-pick --since \n>>\n>> or maybe syntax similar to git cherry where the upstream, head,\n>> and limit can be specified. Or the .. syntax would work.\n>>\n>>\n>> Here's my use case:\n>>\n>> Two branches, 'A' and 'B'.\n>> 'A' is the master branch.\n>> 'B' was forked some time ago and is in bug fix only mode.\n>> Much of 'A' and 'B' are still the same, but there have been\n>> some intrusive changes made to 'A' that should not go into 'B'.\n>\n> You forgot to say \"My objective is to make sure all the good\n> fixes in B are forward ported to A\" but I am assuming that is\n> the case.\n\nYes, that is the case, but the flow is both ways. Other developers\nmay implement fixes in 'A', which must be backported to 'B'. They\ndon't care about 'B'.\n\n>> This is also why I can't just pull from 'B'. rebase may work,\n>> but then of course all of the commit id's change.\n>\n> I do not understand why you cannot merge 'B' into 'A'. From the\n> commit ancestry perspective, merging is exactly the right thing\n> to do if your goal is to forward port all fixes in B to A.\n\nI thought I recalled having problems with a different tree and a\nsimilar situation, where a merge did not do what I expected. I'll\nhave to take a look at that one again and post a scenario if I\nfind one.\n\nI just tried a pull from 'B' into 'A' with this tree, and it worked.\nThe need to cherry-pick from 'A' into 'B' still exists though. The\nwork around using format-patch that Alex suggested does work. Being\nable to cherry-pick a range in a more direct way seems like it would\nbe useful though.\n\n-brandon\n"},{"id":"40231","messageId":"7v8xciga42.fsf@assigned-by-dhcp.cox.net","threadId":"7756","inReplyTo":"Pine.LNX.4.64.0704231208490.4667@torch.nrlssc.navy.mil","subject":"Re: cherry-pick --since ?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-23T19:32:29Z","receivedAt":"2007-04-23T19:32:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Casey writes:\n\n> On Fri, 20 Apr 2007, Junio C Hamano wrote:\n>> Brandon Casey writes:\n>> ...\n>>> Here's my use case:\n>>>\n>>> Two branches, 'A' and 'B'.\n>>> 'A' is the master branch.\n>>> 'B' was forked some time ago and is in bug fix only mode.\n>>> Much of 'A' and 'B' are still the same, but there have been\n>>> some intrusive changes made to 'A' that should not go into 'B'.\n>>\n>> You forgot to say \"My objective is to make sure all the good\n>> fixes in B are forward ported to A\" but I am assuming that is\n>> the case.\n> \n> Yes, that is the case, but the flow is both ways. Other developers\n> may implement fixes in 'A', which must be backported to 'B'. They\n> don't care about 'B'.\n\nThat shows a problem in the project management that needs to be\nfixed independent of what SCM tool you use, doesn't it?\n\nI do not think you would necessarily want to have a VC tsar to\nsay \"No, that is perfectly valid fix for the maintenance branch\nand you should make it go through the maintenance branch, do not\ndirectly commit to the master\". People should be able to\nself-police that, with a general, shared understanding of what\nthe overall process is, and can strive to make it easier for\neverybody.\n\nEven with that, mistakes can happen, and sometimes you may\nrealize that a fix or enhancement is applicable to the\nmaintenance branch as well long after it hit the master branch.\nI would not disagree that you would need to have a way to deal\nwith the ones that need backporting by cherry-picking (otherwise\nwe would not have git-cherry-pick). And I am certainly not\nagainst a cherry-pick that can do more than one commit. What I\nam saying is that having to cherry-pick should be the exception,\nnot the norm, and otherwise there is something wrong in the\nprocess.\n\nIf you want to do a cherry-pick that handles more than one\ncommit, I think you need to worry about sequencing -- how to let\nthe user continue after aborting in the middle and having him\nresolve conflicts. What \"git-rebase --continue\" does already\ncan be used as a model for you to mimick in such an\nimplementation.\n"},{"id":"40255","messageId":"Pine.LNX.4.64.0704231750230.4667@torch.nrlssc.navy.mil","threadId":"7756","inReplyTo":"7v8xciga42.fsf@assigned-by-dhcp.cox.net","subject":"Re: cherry-pick --since ?","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2007-04-23T23:18:42Z","receivedAt":"2007-04-23T23:18:42Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"On Mon, 23 Apr 2007, Junio C Hamano wrote:\n> Brandon Casey writes:\n>\n>> On Fri, 20 Apr 2007, Junio C Hamano wrote:\n>>> Brandon Casey writes:\n>>> ...\n>>>> Here's my use case:\n>>>>\n>>>> Two branches, 'A' and 'B'.\n>>>> 'A' is the master branch.\n>>>> 'B' was forked some time ago and is in bug fix only mode.\n>>>> Much of 'A' and 'B' are still the same, but there have been\n>>>> some intrusive changes made to 'A' that should not go into 'B'.\n>>>\n>>> You forgot to say \"My objective is to make sure all the good\n>>> fixes in B are forward ported to A\" but I am assuming that is\n>>> the case.\n>>\n>> Yes, that is the case, but the flow is both ways. Other developers\n>> may implement fixes in 'A', which must be backported to 'B'. They\n>> don't care about 'B'.\n>\n> That shows a problem in the project management that needs to be\n> fixed independent of what SCM tool you use, doesn't it?\n>\n> I do not think you would necessarily want to have a VC tsar to\n> say \"No, that is perfectly valid fix for the maintenance branch\n> and you should make it go through the maintenance branch, do not\n> directly commit to the master\". People should be able to\n> self-police that, with a general, shared understanding of what\n> the overall process is, and can strive to make it easier for\n> everybody.\n\nAgreed.\n\nI think our case is more similar to a linux 2.6.20 branch and a\n2.6.21 branch. Everybody's working on 2.6.21, but maybe someone is\nstill relying on 2.6.20. That person implements their patches on 2.6.20\nand pushes them to 2.6.21. Meanwhile, important fixes may be applied to\n2.6.21 which is the official development version. So those fixes that\nare applicable to 2.6.20 must be pulled from 2.6.21 by the developer\nwith the interest in 2.6.20.\n\nComments below noted, and thanks for your help.\n\n-brandon\n\n\n> Even with that, mistakes can happen, and sometimes you may\n> realize that a fix or enhancement is applicable to the\n> maintenance branch as well long after it hit the master branch.\n> I would not disagree that you would need to have a way to deal\n> with the ones that need backporting by cherry-picking (otherwise\n> we would not have git-cherry-pick). And I am certainly not\n> against a cherry-pick that can do more than one commit. What I\n> am saying is that having to cherry-pick should be the exception,\n> not the norm, and otherwise there is something wrong in the\n> process.\n>\n> If you want to do a cherry-pick that handles more than one\n> commit, I think you need to worry about sequencing -- how to let\n> the user continue after aborting in the middle and having him\n> resolve conflicts. What \"git-rebase --continue\" does already\n> can be used as a model for you to mimick in such an\n> implementation.\n>\n>\n"},{"id":"118095","messageId":"24512201.post@talk.nabble.com","threadId":"7756","inReplyTo":"Pine.LNX.4.64.0704201100050.4667@torch.nrlssc.navy.mil","subject":"Git range merge (cherry-pick a range)","fromName":"bshOriginal","fromEmail":"mindplayintricks@gmx.de","sentAt":"2009-07-16T08:11:23Z","receivedAt":"2009-07-16T08:11:23Z","isPatch":false,"sender":{"key":"mindplayintricks@gmx.de","avatar":null},"body":"\nPlaying around with GIT, we encountered the following strange situation for\nwhich we would\nlike to have an answer:\n\nScenario\n========\n\nWe want to merge the range B to D from branch B1 to master\n\nMaster: o-\n \\\nBranch B1: A-B-C-D-E\n\n\nCommit B:\n---------\nFluidSolver::FluidSolver(int argc, char* argv[]) {\n init(argc, argv);\n // test edit 1: a + b\n}\n\nCommit C:\n--------\nFluidSolver::FluidSolver(int argc, char* argv[]) {\n init(argc, argv);\n // test edit 1: a + b\n // test edit 2: a - b\n}\n\nCommit D:\n--------\nFluidSolver::FluidSolver(int argc, char* argv[]) {\n init(argc, argv);\n // test edit 1: a + b\n // test edit 2: a - b\n // test edit 3: a * b\n}\n\nCommit E:\n--------\nFluidSolver::FluidSolver(int argc, char* argv[]) {\n init(argc, argv);\n // test edit 1: a + b\n // test edit 2: a - b\n // test edit 3: a * b\n // test edit 4: a / b\n}\n\n\nRange merge (the GIT way):\n=========================\n\n1) Switch to Branch B1\n\n2) Create a temporary branch which does not contain anything beyond commit D\n\n $ git checkout -b volatileBranch D\n\n Master: o-\n \\\n Branch B1: A-B-C-D-E\n \\\n Branch volatileBranch: (A)-(B)-(C)-(D)\n\n3) Rebase volatile branch to master from commit (B) to master's HEAD\n git rebase --onto master (A) \n\n\n Branch volatileBranch: (B)-(C)-(D)\n /\n Master: o-\n \\\n Branch B1: A-B-C-D-E\n \n\nRebasing output:\n----------------\n\nFirst, rewinding head to replay your work on top of it...\nApplying: test edit 2: a - b\nerror: patch failed: fluidsolver.cpp:28\nerror: fluidsolver.cpp: patch does not apply\nUsing index info to reconstruct a base tree...\nFalling back to patching base and 3-way merge...\nAuto-merging fluidsolver.cpp\nCONFLICT (content): Merge conflict in fluidsolver.cpp\nFailed to merge in the changes.\nPatch failed at 0001 test edit 2: a - b\n\n\nWhen you have resolved this problem run \"git rebase --continue\".\nIf you would prefer to skip this patch, instead run \"git rebase --skip\".\nTo restore the original branch and stop rebasing run \"git rebase --abort\".\n\n\nConflicts:\n----------\nFluidSolver::FluidSolver(int argc, char* argv[]) {\n init(argc, argv);\n<<<<<<< HEAD:fluidsolver.cpp\n=======\n // test edit 1: a + b\n // test edit 2: a - b\n>>>>>>> test edit 2: a - b:fluidsolver.cpp\n}\n\n\nAfter manually resolving the conflict and continuing the rebasing \nwith git rebase --continue, we are finally finished.\n\nSince we only had updates in branch 1, it is astonishing that we get a\nconflict at all.\nSame situation works like a charme in subversion.\nWe would be happy to get an explanation for this merge bahaviour, since \nmany edits in large projects could as a matter of principle result a lot of\nmerge conflicts\nwhich all have to be treated manually.\n\nWe believe that GIT's interface for range merges needs to get more user\nfriendly.\nSince steps 1) - 3) use already developed components of GIT, there should be\na layer above 'em\nwhich performs a range merge by internally calling 1) - 3).\n\nExample: git cherry-pick $from_branch@startCommitHash\n$to_branch@endCommitHash \n\n\n\nGreetings,\n\nBabak Sayyid Hosseini\n\n\n\n\n\n\n-- \nView this message in context: http://www.nabble.com/cherry-pick---since---tp10105685p24512201.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"118108","messageId":"4A5F10A6.80003@drmicha.warpmail.net","threadId":"7756","inReplyTo":"24512201.post@talk.nabble.com","subject":"Re: Git range merge (cherry-pick a range)","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-07-16T11:36:06Z","receivedAt":"2009-07-16T11:36:06Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"bshOriginal venit, vidit, dixit 16.07.2009 10:11:\n> \n> Playing around with GIT, we encountered the following strange situation for\n> which we would\n> like to have an answer:\n> \n> Scenario\n> ========\n> \n> We want to merge the range B to D from branch B1 to master\n> \n> Master: o-\n> \\\n> Branch B1: A-B-C-D-E\n> \n\nDid you use a monospaced font when composing this e-mail? All graphs\ncome out disconnect/distorted when reading your e-mail with a monospaced\nfont.\n\nI assume that above, a is the first additional commit of B1 which\nbranches off o.\n\n> \n> Commit B:\n> ---------\n> FluidSolver::FluidSolver(int argc, char* argv[]) {\n> init(argc, argv);\n> // test edit 1: a + b\n> }\n> \n> Commit C:\n> --------\n> FluidSolver::FluidSolver(int argc, char* argv[]) {\n> init(argc, argv);\n> // test edit 1: a + b\n> // test edit 2: a - b\n> }\n> \n> Commit D:\n> --------\n> FluidSolver::FluidSolver(int argc, char* argv[]) {\n> init(argc, argv);\n> // test edit 1: a + b\n> // test edit 2: a - b\n> // test edit 3: a * b\n> }\n> \n> Commit E:\n> --------\n> FluidSolver::FluidSolver(int argc, char* argv[]) {\n> init(argc, argv);\n> // test edit 1: a + b\n> // test edit 2: a - b\n> // test edit 3: a * b\n> // test edit 4: a / b\n> }\n> \n> \n> Range merge (the GIT way):\n> =========================\n> \n> 1) Switch to Branch B1\n> \n> 2) Create a temporary branch which does not contain anything beyond commit D\n> \n> $ git checkout -b volatileBranch D\n> \n> Master: o-\n> \\\n> Branch B1: A-B-C-D-E\n> \\\n> Branch volatileBranch: (A)-(B)-(C)-(D)\n> \n> 3) Rebase volatile branch to master from commit (B) to master's HEAD\n> git rebase --onto master (A) \n> \n> \n> Branch volatileBranch: (B)-(C)-(D)\n> /\n> Master: o-\n> \\\n> Branch B1: A-B-C-D-E\n> \n> \n> Rebasing output:\n> ----------------\n> \n> First, rewinding head to replay your work on top of it...\n> Applying: test edit 2: a - b\n> error: patch failed: fluidsolver.cpp:28\n> error: fluidsolver.cpp: patch does not apply\n> Using index info to reconstruct a base tree...\n> Falling back to patching base and 3-way merge...\n> Auto-merging fluidsolver.cpp\n> CONFLICT (content): Merge conflict in fluidsolver.cpp\n> Failed to merge in the changes.\n> Patch failed at 0001 test edit 2: a - b\n> \n> \n> When you have resolved this problem run \"git rebase --continue\".\n> If you would prefer to skip this patch, instead run \"git rebase --skip\".\n> To restore the original branch and stop rebasing run \"git rebase --abort\".\n> \n> \n> Conflicts:\n> ----------\n> FluidSolver::FluidSolver(int argc, char* argv[]) {\n> init(argc, argv);\n> <<<<<<< HEAD:fluidsolver.cpp\n> =======\n> // test edit 1: a + b\n> // test edit 2: a - b\n>>>>>>>> test edit 2: a - b:fluidsolver.cpp\n> }\n> \n> \n> After manually resolving the conflict and continuing the rebasing \n> with git rebase --continue, we are finally finished.\n> \n> Since we only had updates in branch 1, it is astonishing that we get a\n> conflict at all.\n> Same situation works like a charme in subversion.\n\nAhem, how could /anything/ work like a charm in subversion? (I've been\nusing it myself.)\n\nSeriously, if, in subversion, you merge -rA:D onto master then\nsubversion only computes the diff between A and D and applies it to\nmaster. You an do this in git as well, of course, but that's not a merge\nand does not preserve individual commit messages.\n\n> We would be happy to get an explanation for this merge bahaviour, since \n> many edits in large projects could as a matter of principle result a lot of\n> merge conflicts\n> which all have to be treated manually.\n> \n> We believe that GIT's interface for range merges needs to get more user\n> friendly.\n> Since steps 1) - 3) use already developed components of GIT, there should be\n> a layer above 'em\n> which performs a range merge by internally calling 1) - 3).\n> \n> Example: git cherry-pick $from_branch@startCommitHash\n> $to_branch@endCommitHash \n> \n\nIf I read you graphs correctly you could just as well fast-forward\nmaster to D (using reset or merge) and then \"rebase -i\" in order to\nremove A.\n\nAlternatively, you can use \"git format-patch --stdout revrange | git am\".\n\nMichael\n"},{"id":"118111","messageId":"4A5F2090.8090004@drmicha.warpmail.net","threadId":"7756","inReplyTo":"6efe9a9b0907160516o75641919wd1eecf5229aea895@mail.gmail.com","subject":"Re: Git range merge (cherry-pick a range)","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-07-16T12:44:00Z","receivedAt":"2009-07-16T12:44:00Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Babak S. H. venit, vidit, dixit 16.07.2009 14:16:\n> Hello Micheal,\n> thank you for the response... I will try to answer inline as I read...\n...\n> \n> Did you use a monospaced font when composing this e-mail? All graphs\n> come out disconnect/distorted when reading your e-mail with a monospaced\n> font.\n> \n> \n> \n> What a pity. I pasted the text out of the editor (vi | Font: lucida\n> console 8) in the web form.\n> Anyway I attach my original posting in a file to this email. I hope you\n> can open that undistorted.\n\nYep, it's fine.\n\n> \n> \n> \n> \n> \n> I assume that above, a is the first additional commit of B1 which\n> branches off o.\n> \n> \n> \n> Correct.\n> \n> \n> \n> \n> \n> >\n> > Commit B:\n> > ---------\n> > FluidSolver::FluidSolver(int argc, char* argv[]) {\n> > init(argc, argv);\n> > // test edit 1: a + b\n> > }\n> >\n> > Commit C:\n> > --------\n> > FluidSolver::FluidSolver(int argc, char* argv[]) {\n> > init(argc, argv);\n> > // test edit 1: a + b\n> > // test edit 2: a - b\n> > }\n> >\n> > Commit D:\n> > --------\n> > FluidSolver::FluidSolver(int argc, char* argv[]) {\n> > init(argc, argv);\n> > // test edit 1: a + b\n> > // test edit 2: a - b\n> > // test edit 3: a * b\n> > }\n> >\n> > Commit E:\n> > --------\n> > FluidSolver::FluidSolver(int argc, char* argv[]) {\n> > init(argc, argv);\n> > // test edit 1: a + b\n> > // test edit 2: a - b\n> > // test edit 3: a * b\n> > // test edit 4: a / b\n> > }\n> >\n> >\n> > Range merge (the GIT way):\n> > =========================\n> >\n> > 1) Switch to Branch B1\n> >\n> > 2) Create a temporary branch which does not contain anything\n> beyond commit D\n> >\n> > $ git checkout -b volatileBranch D\n> >\n> > Master: o-\n> > \\\n> > Branch B1: A-B-C-D-E\n> > \\\n> > Branch volatileBranch: (A)-(B)-(C)-(D)\n> >\n> > 3) Rebase volatile branch to master from commit (B) to master's HEAD\n> > git rebase --onto master (A)\n> >\n> >\n> > Branch volatileBranch: (B)-(C)-(D)\n> > /\n> > Master: o-\n> > \\\n> > Branch B1: A-B-C-D-E\n> >\n> >\n> > Rebasing output:\n> > ----------------\n> >\n> > First, rewinding head to replay your work on top of it...\n> > Applying: test edit 2: a - b\n> > error: patch failed: fluidsolver.cpp:28\n> > error: fluidsolver.cpp: patch does not apply\n> > Using index info to reconstruct a base tree...\n> > Falling back to patching base and 3-way merge...\n> > Auto-merging fluidsolver.cpp\n> > CONFLICT (content): Merge conflict in fluidsolver.cpp\n> > Failed to merge in the changes.\n> > Patch failed at 0001 test edit 2: a - b\n> >\n> >\n> > When you have resolved this problem run \"git rebase --continue\".\n> > If you would prefer to skip this patch, instead run \"git rebase\n> --skip\".\n> > To restore the original branch and stop rebasing run \"git rebase\n> --abort\".\n> >\n> >\n> > Conflicts:\n> > ----------\n> > FluidSolver::FluidSolver(int argc, char* argv[]) {\n> > init(argc, argv);\n> > <<<<<<< HEAD:fluidsolver.cpp\n> > =======\n> > // test edit 1: a + b\n> > // test edit 2: a - b\n> >>>>>>>> test edit 2: a - b:fluidsolver.cpp\n> > }\n> >\n> >\n> > After manually resolving the conflict and continuing the rebasing\n> > with git rebase --continue, we are finally finished.\n> >\n> > Since we only had updates in branch 1, it is astonishing that we get a\n> > conflict at all.\n> > Same situation works like a charme in subversion.\n> \n> Ahem, how could /anything/ work like a charm in subversion? (I've been\n> using it myself.)\n> \n> \n> \n> Please let's try not to start a belief war. Every version control\n> systems has its quirks and we just\n> try to figure out what the problem in the above described scenario is.\n\nAgreed. (Which is why I started the next paragraph with \"Seriously,\".)\n\n> \n> \n> \n> \n> \n> \n> Seriously, if, in subversion, you merge -rA:D onto master then\n> subversion only computes the diff between A and D and applies it to\n> master. You an do this in git as well, of course, but that's not a merge\n> and does not preserve individual commit messages.\n> \n> \n> \n> Subversion does preserve individual commit messages.\n> Try to pass the --use-merge-history parameter to svn log.\n\nI have to admit that I've ever used svn 1.4x. I do belief though that\neven 1.5 makes a single commit in that situation and reconstructs the\nmerge history from the metadata.\n\n> \n> \n> \n> \n> \n> > We would be happy to get an explanation for this merge bahaviour,\n> since\n> > many edits in large projects could as a matter of principle result\n> a lot of\n> > merge conflicts\n> > which all have to be treated manually.\n> >\n> > We believe that GIT's interface for range merges needs to get more\n> user\n> > friendly.\n> > Since steps 1) - 3) use already developed components of GIT, there\n> should be\n> > a layer above 'em\n> > which performs a range merge by internally calling 1) - 3).\n> >\n> > Example: git cherry-pick $from_branch@startCommitHash\n> > $to_branch@endCommitHash\n> >\n> \n> If I read you graphs correctly you could just as well fast-forward\n> master to D (using reset or merge) and then \"rebase -i\" in order to\n> remove A.\n> \n> Alternatively, you can use \"git format-patch --stdout revrange | git\n> am\".\n> \n> \n> Yes applying a patch is an alternative.\n> But don't you think git needs to provide a more user friendly interface\n> for range merges?\n\nSometimes it's only a matter of workflow. Have you tried the suggestion\nabove?\n\nIn general, in git it's preferable to have merges of feature branches\nrather than cherry picks. So you would rebase the feature branch first\n(rebase -i to remove A) and then merge the result to master. Have you\ntried whether you get conflicts that way? It's really one rebase -i and\none merge.\n\nIf you want to use a patch approach then \"git format-patch|git am\" and\n\"git cherry\" are your options. Currently, git cherry-pick accepts only a\nsingle commit, but if you want to pick the range B through D that would\nbe B^..D in git lingo, so\n\ngit rev-list --reverse --topo-order B^..D | while read rev\ndo\n git cherry-pick $rev || break\ndone\n\nshould do the job (untested!).\n\nCheers,\nMichael\n"},{"id":"118118","messageId":"alpine.LNX.2.00.0907161200480.2147@iabervon.org","threadId":"7756","inReplyTo":"24512201.post@talk.nabble.com","subject":"Re: Git range merge (cherry-pick a range)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-07-16T16:27:33Z","receivedAt":"2009-07-16T16:27:33Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 16 Jul 2009, bshOriginal wrote:\n\n> \n> Playing around with GIT, we encountered the following strange situation for\n> which we would\n> like to have an answer:\n> \n> Scenario\n> ========\n> \n> We want to merge the range B to D from branch B1 to master\n> \n> Master: o-\n> \\\n> Branch B1: A-B-C-D-E\n> \n> \n> Commit B:\n> ---------\n> FluidSolver::FluidSolver(int argc, char* argv[]) {\n> init(argc, argv);\n> // test edit 1: a + b\n> }\n> \n> Commit C:\n> --------\n> FluidSolver::FluidSolver(int argc, char* argv[]) {\n> init(argc, argv);\n> // test edit 1: a + b\n> // test edit 2: a - b\n> }\n> \n> Commit D:\n> --------\n> FluidSolver::FluidSolver(int argc, char* argv[]) {\n> init(argc, argv);\n> // test edit 1: a + b\n> // test edit 2: a - b\n> // test edit 3: a * b\n> }\n> \n> Commit E:\n> --------\n> FluidSolver::FluidSolver(int argc, char* argv[]) {\n> init(argc, argv);\n> // test edit 1: a + b\n> // test edit 2: a - b\n> // test edit 3: a * b\n> // test edit 4: a / b\n> }\n> \n> \n> Range merge (the GIT way):\n> =========================\n> \n> 1) Switch to Branch B1\n> \n> 2) Create a temporary branch which does not contain anything beyond commit D\n> \n> $ git checkout -b volatileBranch D\n> \n> Master: o-\n> \\\n> Branch B1: A-B-C-D-E\n> \\\n> Branch volatileBranch: (A)-(B)-(C)-(D)\n> \n> 3) Rebase volatile branch to master from commit (B) to master's HEAD\n> git rebase --onto master (A) \n> \n> \n> Branch volatileBranch: (B)-(C)-(D)\n> /\n> Master: o-\n> \\\n> Branch B1: A-B-C-D-E\n> \n> \n> Rebasing output:\n> ----------------\n> \n> First, rewinding head to replay your work on top of it...\n> Applying: test edit 2: a - b\n> error: patch failed: fluidsolver.cpp:28\n> error: fluidsolver.cpp: patch does not apply\n> Using index info to reconstruct a base tree...\n> Falling back to patching base and 3-way merge...\n> Auto-merging fluidsolver.cpp\n> CONFLICT (content): Merge conflict in fluidsolver.cpp\n> Failed to merge in the changes.\n> Patch failed at 0001 test edit 2: a - b\n\nWhat's happening here is that the first commit you're keeping adds an edit \nto a version of the file which has the first edit as well, and that first \nedit is right next to the second edit, and so it's reasonably likely that \nthe second edit has to be done differently in order to not require the \nfirst edit.\n\n> When you have resolved this problem run \"git rebase --continue\".\n> If you would prefer to skip this patch, instead run \"git rebase --skip\".\n> To restore the original branch and stop rebasing run \"git rebase --abort\".\n> \n> \n> Conflicts:\n> ----------\n> FluidSolver::FluidSolver(int argc, char* argv[]) {\n> init(argc, argv);\n> <<<<<<< HEAD:fluidsolver.cpp\n> =======\n> // test edit 1: a + b\n> // test edit 2: a - b\n> >>>>>>> test edit 2: a - b:fluidsolver.cpp\n> }\n\nThis is the merge conflict output for the case where you're applying a \nchange which is based on a version with some of the final code already \nthere to a base that doesn't have that code. It's not a necessary \nconflict, but it is a likely conflict (that is, there's a unique logical \nguess as to the right resolution, but there's also a good change that the \nresulting code doesn't work). Of course, if the edits actually overlap, it \nbecomes a necessary conflict.\n\n> After manually resolving the conflict and continuing the rebasing \n> with git rebase --continue, we are finally finished.\n> \n> Since we only had updates in branch 1, it is astonishing that we get a\n> conflict at all.\n> Same situation works like a charme in subversion.\n\nExcept when it generates broken code like a charm...\n\n> We would be happy to get an explanation for this merge bahaviour, since \n> many edits in large projects could as a matter of principle result a lot of\n> merge conflicts\n> which all have to be treated manually.\n> \n> We believe that GIT's interface for range merges needs to get more user\n> friendly.\n> Since steps 1) - 3) use already developed components of GIT, there should be\n> a layer above 'em\n> which performs a range merge by internally calling 1) - 3).\n> \n> Example: git cherry-pick $from_branch@startCommitHash\n> $to_branch@endCommitHash \n\nThe main issue is the:\n\n git ??? --continue\n\nthat you use after you resolve any conflicts. The existing components need \nto be reorganized in order to support doing the correct later steps when a \nmulti-step operation supplied by a higher layer was previously suspended \nfor user assistance in the middle.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"118162","messageId":"24530703.post@talk.nabble.com","threadId":"7756","inReplyTo":"24512201.post@talk.nabble.com","subject":"Re: Git range merge (cherry-pick a range)","fromName":"bshOriginal","fromEmail":"mindplayintricks@gmx.de","sentAt":"2009-07-17T08:41:37Z","receivedAt":"2009-07-17T08:41:37Z","isPatch":false,"sender":{"key":"mindplayintricks@gmx.de","avatar":null},"body":"\nOn Thu, Jul 16, 2009 at 2:44 PM, Michael J Gruber \nwrote:\n\n Babak S. H. venit, vidit, dixit 16.07.2009 14:16:\n >>> Hello Micheal,\n >>> thank you for the response... I will try to answer inline as I\nread...\n \n >>>> Did you use a monospaced font when composing this e-mail? All\ngraphs\n >>>> come out disconnect/distorted when reading your e-mail with a\nmonospaced\n >>>> font.\n \n \n >>> What a pity. I pasted the text out of the editor (vi | Font: lucida\n >>> console 8) in the web form.\n >>> Anyway I attach my original posting in a file to this email. I hope\nyou\n >>> can open that undistorted.\n \n\n >>Yep, it's fine.\n\n \n >>>> I assume that above, a is the first additional commit of B1\nwhich\n >>>> branches off o.\n\n\n >>> Correct.\n \n \n >>>>> Commit B:\n >>>>> ---------\n >>>>> FluidSolver::FluidSolver(int argc, char* argv[]) {\n >>>>> init(argc, argv);\n >>>>> // test edit 1: a + b\n >>>>> }\n >>>>>\n >>>>> Commit C:\n >>>>> --------\n >>>>> FluidSolver::FluidSolver(int argc, char* argv[]) {\n >>>>> init(argc, argv);\n >>>>> // test edit 1: a + b\n >>>>> // test edit 2: a - b\n >>>>> }\n >>>>>\n >>>>> Commit D:\n >>>>> --------\n >>>>> FluidSolver::FluidSolver(int argc, char* argv[]) {\n >>>>> init(argc, argv);\n >>>>> // test edit 1: a + b\n >>>>> // test edit 2: a - b\n >>>>> // test edit 3: a * b\n >>>>> }\n >>>>>\n >>>>> Commit E:\n >>>>> --------\n >>>>> FluidSolver::FluidSolver(int argc, char* argv[]) {\n >>>>> init(argc, argv);\n >>>>> // test edit 1: a + b\n >>>>> // test edit 2: a - b\n >>>>> // test edit 3: a * b\n >>>>> // test edit 4: a / b\n >>>>> }\n >>>>>\n >>>>>\n >>>>> Range merge (the GIT way):\n >>>>> =========================\n >>>>>\n >>>>> 1) Switch to Branch B1\n >>>>>\n >>>>> 2) Create a temporary branch which does not contain anything\n >>>>> beyond commit D\n >>>>>\n >>>>> $ git checkout -b volatileBranch D\n >>>>>\n >>>>> Master: o-\n >>>>> \\\n >>>>> Branch B1: A-B-C-D-E\n >>>>> \\\n >>>>> Branch volatileBranch: (A)-(B)-(C)-(D)\n >>>>>\n >>>>> 3) Rebase volatile branch to master from commit (B) to master's\nHEAD\n >>>>> git rebase --onto master (A)\n >>>>>\n >>>>>\n >>>>> Branch volatileBranch: (B)-(C)-(D)\n >>>>> /\n >>>>> Master: o-\n >>>>> \\\n >>>>> Branch B1: A-B-C-D-E\n >>>>>\n >>>>>\n >>>>> Rebasing output:\n >>>>> ----------------\n >>>>>\n >>>>> First, rewinding head to replay your work on top of it...\n >>>>> Applying: test edit 2: a - b\n >>>>> error: patch failed: fluidsolver.cpp:28\n >>>>> error: fluidsolver.cpp: patch does not apply\n >>>>> Using index info to reconstruct a base tree...\n >>>>> Falling back to patching base and 3-way merge...\n >>>>> Auto-merging fluidsolver.cpp\n >>>>> CONFLICT (content): Merge conflict in fluidsolver.cpp\n >>>>> Failed to merge in the changes.\n >>>>> Patch failed at 0001 test edit 2: a - b\n >>>>>\n >>>>>\n >>>>> When you have resolved this problem run \"git rebase --continue\".\n >>>>> If you would prefer to skip this patch, instead run \"git rebase\n--skip\".\n >>>>> To restore the original branch and stop rebasing run \"git rebase\n--abort\".\n\n >>>>> Conflicts:\n >>>>> ----------\n >>>>> FluidSolver::FluidSolver(int argc, char* argv[]) {\n >>>>> init(argc, argv);\n >>>>> <<<<<<< HEAD:fluidsolver.cpp\n >>>>> =======\n >>>>> // test edit 1: a + b\n >>>>> // test edit 2: a - b\n >>>>> >>>>>>>> test edit 2: a - b:fluidsolver.cpp\n >>>>> }\n \n >>>>> After manually resolving the conflict and continuing the rebasing\n >>>>> with git rebase --continue, we are finally finished.\n \n >>>>> Since we only had updates in branch 1, it is astonishing that we\nget a\n >>>>> conflict at all.\n >>>>> Same situation works like a charme in subversion.\n \n >>>> Ahem, how could /anything/ work like a charm in subversion?\n(I've been\n >>>> using it myself.)\n \n >>> Please let's try not to start a belief war. Every version control\n >>> systems has its quirks and we just\n >>> try to figure out what the problem in the above described scenario\nis.\n\n >>Agreed. (Which is why I started the next paragraph with \"Seriously,\".)\n\n \n >>>> Seriously, if, in subversion, you merge -rA:D onto master then\n >>>> subversion only computes the diff between A and D and applies\nit to\n >>>> master. You an do this in git as well, of course, but that's\nnot a merge\n >>>> and does not preserve individual commit messages.\n >>>>\n\n \n >>> Subversion does preserve individual commit messages.\n >>> Try to pass the --use-merge-history parameter to svn log.\n \n\n >> I have to admit that I've ever used svn 1.4x. I do belief though that\n >> even 1.5 makes a single commit in that situation and reconstructs the\n >> merge history from the metadata.\n\n\n> Maybe. But it works and you can additionally inspect diffs between\n> revisions.\n\n\n \n \n >>>>> We would be happy to get an explanation for this merge bahaviour,\n >>>>> since\n >>>>> many edits in large projects could as a matter of principle result\n >>>>> a lot of merge conflicts which all have to be treated manually.\n\n >>>>> We believe that GIT's interface for range merges needs to get more\n >>>>> user friendly.\n >>>>> Since steps 1) - 3) use already developed components of GIT, there\n >>>>> should be a layer above 'em\n >>>>> which performs a range merge by internally calling 1) - 3).\n >>>>>\n >>>>> Example: git cherry-pick $from_branch@startCommitHash\n >>>>> $to_branch@endCommitHash\n\n >> If I read you graphs correctly you could just as well\nfast-forward\n >> master to D (using reset or merge) and then \"rebase -i\" in order\nto\n >> remove A.\n >>\n >> Alternatively, you can use \"git format-patch --stdout revrange |\ngit\n >> am\".\n \n \n > Yes applying a patch is an alternative.\n > But don't you think git needs to provide a more user friendly\ninterface\n > for range merges?\n\n >> Sometimes it's only a matter of workflow. Have you tried the\nsuggestion\n >> above?\n\n\nYes, many ways lead to Rome..\nPersonally, I think most companies and open source coders are currently\nbound to subversion\nand are keen to start off with a more sophisticated version control system\nas e.g. git, mercurial or darcs. As they are already pretty familiar with\nsubversion,\nI think it is clever to follow established and accepted workflows in case\nthose workflows are really\nequivalent. This enhances the acceptability and is a pro for git in a direct\ncomparison to the\nmentioned alternative distributed version control systems.\n\nI tried out the patch alternative and apart from the fact that\none of the patches could not be directly applied and as a result we again\nfaced the\nsame merge conflict, everything worked out the way it ought to.\n\n\n \n >> In general, in git it's preferable to have merges of feature branches\n >> rather than cherry picks. So you would rebase the feature branch\nfirst\n >> (rebase -i to remove A) and then merge the result to master. Have you\n >> tried whether you get conflicts that way? It's really one rebase -i\nand\n >> one merge.\n\n\n\n\nNo I must admit that I did not try that one out, but I believe it is pretty\nmuch the same\nthing I did. I branched from revision D dropping out revision E.\nThen I rebased in a way that everything above revision A was merge relevant\ncropping A.\n==> A CROP B - C - D CROP E\n\n \n\n\n > If you want to use a patch approach then \"git format-patch|git am\" and\n > \"git cherry\" are your options. Currently, git cherry-pick accepts only\na\n > single commit, but if you want to pick the range B through D that\nwould\n > be B^..D in git lingo, so\n\n > git rev-list --reverse --topo-order B^..D | while read rev\n > do\n > git cherry-pick $rev || break\n > done\n\n\n\nThe above lines look correct to me.\nBut again, if git really wants to be the next king version control system,\nit has\nto be more user friendly. You and me are comfortable with the command line.\nThere are a lot of GUI users though, that are overstrained with all that.\nI hope git implements a few more top level functions to simplify specific\noperations\nas it seems to be a really nice VCS.\n\nHave a nicce day.\n\nBabak Sayyid Hosseini\n\n\n \n\n\n > should do the job (untested!).\n\n > Cheers,\n > Michael\n\n\n\n\n-- \nRegards.\n\nBabak Sayyid Hosseini\n-- \nView this message in context: http://www.nabble.com/cherry-pick---since---tp10105685p24530703.html\nSent from the git mailing list archive at Nabble.com.\n"}]}