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
>