Re: Itches with the current rev spec

From: Phil Hord <phil.hord@gmail.com>
Date: Apr 25, 2013, 19:08 UTC
Message-ID: <CABURp0pSMRZLLDz8hgXxMtTtx-vpn8SSAi-16tyw2+J+ttUQTg@mail.gmail.com>
In-Reply-To: <CALkWK0n97VLtiR96VEy86645NVoDL2rS-g7LBuLb=JpncdH6VA@mail.gmail.com>

On Thu, Apr 25, 2013 at 1:07 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

> 2. git rebase -i master fails unless I've rebased my branch on top of
> master.  I always wished I could do the equivalent of 'git rebase -i
> master..', but I can't.

In what way does it fail? It seems to work ok for me. Do you mean that it chooses extra commits you did not want?

Maybe you expect rebase--interactive will only result in changes to commits you touch in the todo list and it will not actually rebase anything. Is that the goal?

I have been thinking of adding a targeted "rebase -i" extension. I often use rebase -i to change one commit in recent history or to squash some fixup into place. The trip through $EDITOR to do this seems disruptive to my thinking. So I would like to be able to do this:

   git rebase --edit $REF

which should act the same as

  GIT_EDITOR='sed -i "s/^pick $REF/edit $REF/"' \
  git rebase -i $REF^

Except that $REF could be any ref and not just the exact SHA1-abbreviation given in todo.

The change I imagine allows --fixup, --reword, --squash, etc. It might even allow multiple instances of each.

I haven't thought through how to handle the case where there are merges in the way, but I do already suppose that the command will simply fail if a ref is not an ancestor of HEAD.

Maybe this is too simple for your workflow, though. As I said, I did not understand your itch.

Phil