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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin venit, vidit, dixit 27.02.2009 11:30:
> 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
> 

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
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux