On Thu, Apr 25, 2013 at 1:07 AM, Ramkumar Ramachandra
<artag...@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

   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.

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

Reply via email to