threads / discuss / 18042
Subject: FEATURE suggestion git commit --amend <ref>
Caleb Cushinggit 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
Sverre RabbelierRe: FEATURE suggestion git commit --amend <ref>
Heya,
On Fri, Feb 27, 2009 at 08:45, Caleb Cushing <xenoterracide@gmail.com> 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
Wincent ColaiutaRe: FEATURE suggestion git commit --amend <ref>
El 27/2/2009, a las 9:37, Sverre Rabbelier escribió:
> Heya, > > On Fri, Feb 27, 2009 at 08:45, Caleb Cushing > <xenoterracide@gmail.com> 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/'?
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
Johannes SchindelinRe: 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
Michael J GruberRe: FEATURE suggestion git commit --amend <ref>
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