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