Re: Interactive rebase with pre-built script?
Andrew Wong: Instead of rebasing to HEAD~, you should be able to do: git rebase -i HEAD Would you look at that, that actually works. So much for not testing that. Thanks, that makes it a lot easier. Instead of appending your own recipe, you could also abuse the EDITOR environment variable. Say your recipe is stored in a file called my_recipe. Then, you could do this: env EDITOR=cp my_recipe git rebase -i HEAD But this could potentially be dangerous because if rebase fires up a editor for any other reason (e.g. having a reword or squash in your recipe), then the commit message will be messed up. So you need to make sure your recipe won't trigger any editor except for the recipe. Indeed, that's why I don't want to do that. Perhaps I should add some switch that would append the contents of a specific file to the prebuild recipe, I guess that should be fairly easy. The question is what to call the switch. -- \\// Peter - http://www.softwolves.pp.se/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interactive rebase with pre-built script?
On 09/13/2012 09:33 AM, Peter Krefting wrote: But this could potentially be dangerous because if rebase fires up a editor for any other reason (e.g. having a reword or squash in your recipe), then the commit message will be messed up. So you need to make sure your recipe won't trigger any editor except for the recipe. Indeed, that's why I don't want to do that. Are you expecting to have reword or squash in your recipe? If not, I think you should be safe. If there's a conflict, then rebase will stop, and next time you run git rebase --continue, your normal editor will be back. From your original description, it sounded like you are only doing pick. On 09/13/2012 09:33 AM, Peter Krefting wrote: Perhaps I should add some switch that would append the contents of a specific file to the prebuild recipe, I guess that should be fairly easy. The question is what to call the switch. How about calling the switch --todo? i.e. rebase -i --todo my_recipe Can we also get some inputs from others on whether adding this switch to rebase -i is desirable? On 09/11/2012 11:35 AM, Junio C Hamano wrote: Using git cherry-pick $(git rev-list --reverse .) ought to work. And I assume what Junio suggested doesn't help with your problem? Because of the time skewed behavior? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interactive rebase with pre-built script?
On 09/11/2012 02:32 AM, Peter Krefting wrote: Now, to my question. Is there an easy way to run interactive rebase on the upstream branch with this recipe? The best we have come up with so far is git checkout master # the upstream branch git rebase -i HEAD~ and then just append everything from the generated recipe. Instead of rebasing to HEAD~, you should be able to do: git rebase -i HEAD The default recipe should then just be noop, and you can replace the whole default recipe with your recipe. This should also work even if the last commit was a merge. Instead of appending your own recipe, you could also abuse the EDITOR environment variable. Say your recipe is stored in a file called my_recipe. Then, you could do this: env EDITOR=cp my_recipe git rebase -i HEAD But this could potentially be dangerous because if rebase fires up a editor for any other reason (e.g. having a reword or squash in your recipe), then the commit message will be messed up. So you need to make sure your recipe won't trigger any editor except for the recipe. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Interactive rebase with pre-built script?
Hi! At $DAYJOB, we have a lot of code flowing from a central repository to repositories which hold refinitions and ports of the code from the central repository. Often enough the people working on the porting repositories find bugs in the code from the central repository, and want to submit patches upstream. We want to get these patches upstream in the easiest possible manner, and a clever colleague of mine came up with this recipe, to be run from the downstream repository: git log --reverse --format=pick %h %s master.. -- common_paths changes.txt This gives a list of the commits changing the code in the common paths (we try to make sure to make them in separate changesets, not touching the downstream code), in a format that can be used as input to git rebase --interactive. Now, to my question. Is there an easy way to run interactive rebase on the upstream branch with this recipe? The best we have come up with so far is git checkout master # the upstream branch git rebase -i HEAD~ and then just append everything from the generated recipe. This doesn't play well if the last commit is a merge, though (making a dummy commit and just removing it from the default rebase recipe works for that case, though). I was thinking about using git cherry-pick with a list of commits, rebase is better at helping with conflicts and such. -- \\// Peter - http://www.softwolves.pp.se/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interactive rebase with pre-built script?
Peter Krefting pe...@softwolves.pp.se writes: I was thinking about using git cherry-pick with a list of commits, rebase is better at helping with conflicts and such. Because the three-way merge done by rebase is exactly the same as cherry-pick, I do not think I understand the reasoning behind this statement at all. After the command gives you control back asking for your help to resolve conflicted merge, the sequencing rebase gives is certainly better than a hand-rolled loop: git rev-list --reverse . | while read commit do git cherry-pick $commit || break done though. Using git cherry-pick $(git rev-list --reverse .) ought to work. It may misbehave only if you have a time skewed commits, but the 'mz/cherry-pick-cmdline-order' topic recently fixed (it is in 'master' and will be in 1.8.0). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
