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/

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.

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/

On 09/13/2012 09:33 AM, Peter Krefting wrote:

quoted

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?