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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
