{"thread":{"id":"31497","subject":"Interactive rebase with pre-built script?","startedAt":"2012-09-11T06:32:34Z","lastAt":"2012-09-13T18:08:31Z","messageCount":5,"participants":["Peter Krefting","Junio C Hamano","Andrew Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"198755","messageId":"alpine.DEB.2.00.1209110725130.8398@ds9.cixit.se","threadId":"31497","inReplyTo":null,"subject":"Interactive rebase with pre-built script?","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2012-09-11T06:32:34Z","receivedAt":"2012-09-11T06:32:34Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Hi!\n\nAt $DAYJOB, we have a lot of code flowing from a central repository \nto repositories which hold refinitions and ports of the code from the \ncentral repository. Often enough the people working on the porting \nrepositories find bugs in the code from the central repository, and \nwant to submit patches upstream.\n\nWe want to get these patches upstream in the easiest possible manner, \nand a clever colleague of mine came up with this recipe, to be run \nfrom the downstream repository:\n\n   git log --reverse --format=\"pick %h %s\" master.. -- common_paths > \nchanges.txt\n\nThis gives a list of the commits changing the code in the common paths \n(we try to make sure to make them in separate changesets, not touching \nthe downstream code), in a format that can be used as input to git \nrebase --interactive.\n\nNow, to my question. Is there an easy way to run interactive rebase \non the upstream branch with this recipe? The best we have come up with \nso far is\n\n   git checkout master # the upstream branch\n   git rebase -i HEAD~\n\nand then just append everything from the generated recipe. This \ndoesn't play well if the last commit is a merge, though (making a \ndummy commit and just removing it from the default rebase recipe works \nfor that case, though).\n\nI was thinking about using git cherry-pick with a list of commits, \nrebase is better at helping with conflicts and such.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"198784","messageId":"7vliggk1xn.fsf@alter.siamese.dyndns.org","threadId":"31497","inReplyTo":"alpine.DEB.2.00.1209110725130.8398@ds9.cixit.se","subject":"Re: Interactive rebase with pre-built script?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-11T15:35:16Z","receivedAt":"2012-09-11T15:35:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Krefting <peter@softwolves.pp.se> writes:\n\n> I was thinking about using git cherry-pick with a list of commits,\n> rebase is better at helping with conflicts and such.\n\nBecause the three-way merge done by rebase is exactly the same as\ncherry-pick, I do not think I understand the reasoning behind this\nstatement at all.  After the command gives you control back asking\nfor your help to resolve conflicted merge, the sequencing \"rebase\"\ngives is certainly better than a hand-rolled loop:\n\n\tgit rev-list --reverse ..... |\n\twhile read commit\n        do\n        \tgit cherry-pick \"$commit\" || break\n\tdone\n\nthough.\n\nUsing \"git cherry-pick $(git rev-list --reverse .....)\" ought to\nwork.  It may misbehave only if you have a time skewed commits, but\nthe 'mz/cherry-pick-cmdline-order' topic recently fixed (it is in\n'master' and will be in 1.8.0).\n"},{"id":"198854","messageId":"5050BA90.2010105@sohovfx.com","threadId":"31497","inReplyTo":"alpine.DEB.2.00.1209110725130.8398@ds9.cixit.se","subject":"Re: Interactive rebase with pre-built script?","fromName":"Andrew Wong","fromEmail":"andrew.w-lists@sohovfx.com","sentAt":"2012-09-12T16:38:40Z","receivedAt":"2012-09-12T16:38:40Z","isPatch":false,"sender":{"key":"andrew.w-lists@sohovfx.com","avatar":null},"body":"On 09/11/2012 02:32 AM, Peter Krefting wrote:\n> Now, to my question. Is there an easy way to run interactive rebase on \n> the upstream branch with this recipe? The best we have come up with so \n> far is\n>\n>   git checkout master # the upstream branch\n>   git rebase -i HEAD~\n>\n> and then just append everything from the generated recipe.\nInstead of rebasing to \"HEAD~\", you should be able to do:\n     git rebase -i HEAD\nThe default recipe should then just be \"noop\", and you can replace the \nwhole default recipe with your recipe. This should also work even if the \nlast commit was a merge.\n\nInstead of appending your own recipe, you could also abuse the EDITOR \nenvironment variable.\nSay your recipe is stored in a file called \"my_recipe\". Then, you could \ndo this:\n     env EDITOR=\"cp my_recipe\" git rebase -i HEAD\n\nBut this could potentially be dangerous because if \"rebase\" fires up a \neditor for any other reason (e.g. having a \"reword\" or \"squash\" in your \nrecipe), then the commit message will be messed up. So you need to make \nsure your recipe won't trigger any editor except for the recipe.\n"},{"id":"198917","messageId":"alpine.DEB.2.00.1209131431580.20765@ds9.cixit.se","threadId":"31497","inReplyTo":"5050BA90.2010105@sohovfx.com","subject":"Re: Interactive rebase with pre-built script?","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2012-09-13T13:33:46Z","receivedAt":"2012-09-13T13:33:46Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Andrew Wong:\n\n> Instead of rebasing to \"HEAD~\", you should be able to do:\n>    git rebase -i HEAD\n\nWould you look at that, that actually works. So much for not testing \nthat. Thanks, that makes it a lot easier.\n\n> Instead of appending your own recipe, you could also abuse the EDITOR \n> environment variable.\n> Say your recipe is stored in a file called \"my_recipe\". Then, you could do \n> this:\n>    env EDITOR=\"cp my_recipe\" git rebase -i HEAD\n>\n> But this could potentially be dangerous because if \"rebase\" fires up a editor \n> for any other reason (e.g. having a \"reword\" or \"squash\" in your recipe), \n> then the commit message will be messed up. So you need to make sure your \n> recipe won't trigger any editor except for the recipe.\n\nIndeed, that's why I don't want to do that.\n\nPerhaps I should add some switch that would append the contents of a \nspecific file to the prebuild recipe, I guess that should be fairly \neasy. The question is what to call the switch.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"198949","messageId":"5052211F.6060000@sohovfx.com","threadId":"31497","inReplyTo":"alpine.DEB.2.00.1209131431580.20765@ds9.cixit.se","subject":"Re: Interactive rebase with pre-built script?","fromName":"Andrew Wong","fromEmail":"andrew.w@sohovfx.com","sentAt":"2012-09-13T18:08:31Z","receivedAt":"2012-09-13T18:08:31Z","isPatch":false,"sender":{"key":"andrew.w@sohovfx.com","avatar":null},"body":"On 09/13/2012 09:33 AM, Peter Krefting wrote:\n>> But this could potentially be dangerous because if \"rebase\" fires up \n>> a editor for any other reason (e.g. having a \"reword\" or \"squash\" in \n>> your recipe), then the commit message will be messed up. So you need \n>> to make sure your recipe won't trigger any editor except for the recipe.\n> Indeed, that's why I don't want to do that. \nAre you expecting to have \"reword\" or \"squash\" in your recipe? If not, I \nthink you should be safe.\nIf there's a conflict, then rebase will stop, and next time you run \"git \nrebase --continue\", your normal editor will be back.\n From your original description, it sounded like you are only doing \"pick\".\n\nOn 09/13/2012 09:33 AM, Peter Krefting wrote:\n> Perhaps I should add some switch that would append the contents of a \n> specific file to the prebuild recipe, I guess that should be fairly \n> easy. The question is what to call the switch.\nHow about calling the switch \"--todo\"? i.e. \"rebase -i --todo my_recipe\"\nCan we also get some inputs from others on whether adding this switch to \n\"rebase -i\" is desirable?\n\nOn 09/11/2012 11:35 AM, Junio C Hamano wrote:\n> Using \"git cherry-pick $(git rev-list --reverse .....)\" ought to work.\nAnd I assume what Junio suggested doesn't help with your problem? \nBecause of the time skewed behavior?\n"}]}