FEATURE suggestion git commit --amend <ref>

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.

-- 
Caleb Cushing

http://xenoterracide.blogspot.com

Heya,

On Fri, Feb 27, 2009 at 08:45, Caleb Cushing [off-list ref] 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.

Ah, yes, I would like this feature as well. But this could probably be
solved with a custom editor script that does a simple sed 's/pick
$TARGET/edit $TARGET/'?

-- 
Cheers,

Sverre Rabbelier

El 27/2/2009, a las 9:37, Sverre Rabbelier escribió:

Heya,

On Fri, Feb 27, 2009 at 08:45, Caleb Cushing  
[off-list ref] wrote:

quoted

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.

Ah, yes, I would like this feature as well. But this could probably be
solved with a custom editor script that does a simple sed 's/pick
$TARGET/edit $TARGET/'?

I'm not sure if this proposed feature would actually be very convenient.

Think about the way "git commit --amend" currently works: it just  
takes the current index and uses it to create a new commit, replacing  
the current HEAD commit, and of course gives the user the opportunity  
to edit the commit message.

If you want to "git commit --amend HEAD~2" then how will you prepare  
your index in a convenient fashion?

The way "rebase -i" works is to actually stop on the "edit" commit so  
that you have an opportunity to tweak things in the index (or even  
create a _series_ of new commits). But giving the user a chance to  
edit _after_ doing "git commit --amend HEAD~2" would be a little  
surprising seeing as "git commit" generally means "create a commit  
object right now". And the user would then have to indicate that he/ 
she was ready to go ahead and actually create the commit; and so you'd  
need an ugly "git commit --continue" or similar to indicate that  
you're done tweaking.

Alternatively, you could say you don't care about the index and you  
only want to edit the commit message. Then you'd be breaking with the  
existing semantics of "git commit --amend" which _does_ pay attention  
to the state of the index.

Basically, I think that the easiest workflow for doing what you want  
to do is actually just to use "git rebase -i". And if you have a very  
specific special-case workflow that you want to automate then you  
could indeed make a custom editor script, but it would have such a  
narrow, specialized use that I'd question the value of it.

Cheers,
Wincent

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

Johannes Schindelin venit, vidit, dixit 27.02.2009 11:30:

Hi,

On Fri, 27 Feb 2009, Caleb Cushing wrote:

quoted

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

FWIW I share all your caveats, especially the fact that - as you point
out - we're really talking rebase here, not commit--amend.

In the end I think Caleb is asking for something like

git rebase --single $COMMIT

to mean

sha=$(git rev-parse --short $COMMIT)
GIT_EDITOR='sed -i -e"/'$sha'/s/pick/edit/"' git rebase -i $COMMIT^

which, again, is easy in shell, and left as an exercise regarding the
implementation as a git alias "rebase-one"...

Michael