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