Re: [RFH] rebase -i optimization

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Feb 27, 2009, 01:10 UTC
Message-ID: <slrngqefbi.g56.sitaramc@sitaramc.homelinux.net>
In-Reply-To: <fabb9a1e0902260655g53fa1e1fg7e4aa76b0f3a80fc@mail.gmail.com>

On 2009-02-26, Sverre Rabbelier <srabbelier@gmail.com> wrote:

Show 8 quoted lines

> 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 :-)