On 2009-02-26, Sverre Rabbelier <srabbelier@xxxxxxxxx> wrote:
> I am currently working on a large set of patches for Melange, and as
> such I'm using rebase -i a lot to polish things a bit. I do this
> mainly by 'git rebase -i master' from my topic branch, then change on
> of the 'pick' lines into an 'edit', and then fix up the commit and
> 'git rebase --continue'. Now I notice I'm waiting a lot for 'rebase
> -i' to finish picking the first bunch of commits that I didn't change.
> Now obviously I couldof done 'git rebase -i <foo>', but then I have
> first figure out what the last commit I want to change is.
you could, in theory, do it with a custom "EDITOR" variable
that actually points to a script you write. This script
will invoke the normal editor just as now, but if it finds
that the resulting file has pick line(s) before the first
edit line, it aborts the rebase by sending back an empty
file, and print out a suitable rebase command that you just
click-and-paste :-)
Any other combination it just sends through as normal (like
if the first non-pick line was a 'squash', for instance).
Yes this is a kludge but it gets your job done with a
minimum of fuss asap.
Regards,
Sitaram
PS: Even more fun...
I tested a script that looks like this:
#!/bin/bash
vim "$@"
# -- parse $1 (which will be # .git/rebase-merge/rebase-todo
# really) to pick the correct SHA you need --
unset EDITOR
git rebase --abort
git rebase -i the-SHA-you-picked
When it finishes the inner rebase it does protest mildly
(something about grep not finding that same file), a remnant
of the outer rebase... but it seems to work fine.
This removes even the extra step of having the outer rebase
print something that you have to then copy/paste :-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
