Thread (5 messages) flat view 5 messages, 5 authors, 2016-06-15

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

From: Wincent Colaiuta <hidden>
Date: 2016-06-15 22:46:17

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help