Re: FEATURE suggestion git commit --amend <ref>

Hi,

On Fri, 27 Feb 2009, Caleb Cushing wrote:

git rebase -i seems a little more tedious/unfriendly than I'd like if 
all I want to do is edit HEAD~2 (assuming no merges) it's a bit of a 
pain to do a rebase -i and then pick which patches to edit. might be 
nice to be able to do stuff like git commit --amend <ref> and have that 
call rebase (as I think not rebasing is impossible?) with edit only on 
the ref I picked.

hopefully I've explained well enough.

Yes, but IMHO you did not consider the undesired side effects well enough.

For example: What about merges?

To be clear: amending a merge is not just a matter of "rebase -i 
<commit>^" with a custom script, and even worse, there could be merges 
between the commit you want to amend and the current HEAD.  That is a 
complete Pandora box right there.

Also, your amended changes could break reapplication of the later commits.  
So "git commit --amend <ref-other-than-HEAD>" is _semantically_ different 
from "git commit --amend".

Of course, there is also the problem that <ref> might not be an ancestor 
of HEAD to begin with.

And that the specified commit could be part of more than one branch, 
adding to user's confusion when it is only rewritten in the current 
branch.

But more fundamental: is this operation something we want to make _that_ 
easy?  After all, it is _not_ the common case, and it bears such a bunch 
of problems that the user should be made well aware of what she is doing.

All in all, as with many feature requests, I have to say that I see what 
you want, but the side effects are too horrible -- and you did not 
consider them, obviously, otherwise you would have put forward arguments 
as to why the side effects would not matter that much.

Ciao,
Dscho