{"thread":{"id":"18042","subject":"FEATURE suggestion git commit --amend ","startedAt":"2009-02-27T07:45:28Z","lastAt":"2009-02-27T14:49:37Z","messageCount":5,"participants":["Caleb Cushing","Sverre Rabbelier","Wincent Colaiuta","Johannes Schindelin","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"106405","messageId":"81bfc67a0902262345i63386076rbcf6d71ed88c29ac@mail.gmail.com","threadId":"18042","inReplyTo":null,"subject":"FEATURE suggestion git commit --amend ","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2009-02-27T07:45:28Z","receivedAt":"2009-02-27T07:45:28Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"git rebase -i seems a little more tedious/unfriendly than I'd like if\nall I want to do is edit HEAD~2 (assuming no merges) it's a bit of a\npain to do a rebase -i and then pick which patches to edit. might be\nnice to be able to do stuff like git commit --amend and have\nthat call rebase (as I think not rebasing is impossible?) with edit\nonly on the ref I picked.\n\nhopefully I've explained well enough.\n\n-- \nCaleb Cushing\n\nhttp://xenoterracide.blogspot.com\n"},{"id":"106409","messageId":"fabb9a1e0902270037s3355e8e3m1533f86fd3ce2e8f@mail.gmail.com","threadId":"18042","inReplyTo":"81bfc67a0902262345i63386076rbcf6d71ed88c29ac@mail.gmail.com","subject":"Re: FEATURE suggestion git commit --amend ","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-02-27T08:37:06Z","receivedAt":"2009-02-27T08:37:06Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Fri, Feb 27, 2009 at 08:45, Caleb Cushing wrote:\n> git rebase -i seems a little more tedious/unfriendly than I'd like if\n> all I want to do is edit HEAD~2 (assuming no merges) it's a bit of a\n> pain to do a rebase -i and then pick which patches to edit. might be\n> nice to be able to do stuff like git commit --amend and have\n> that call rebase  (as I think not rebasing is impossible?) with edit\n> only on the ref I picked.\n\nAh, yes, I would like this feature as well. But this could probably be\nsolved with a custom editor script that does a simple sed 's/pick\n$TARGET/edit $TARGET/'?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"106417","messageId":"DE8E2AF9-9BE6-4FB9-84EF-650EDAA9881B@wincent.com","threadId":"18042","inReplyTo":"fabb9a1e0902270037s3355e8e3m1533f86fd3ce2e8f@mail.gmail.com","subject":"Re: FEATURE suggestion git commit --amend ","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-02-27T09:55:57Z","receivedAt":"2009-02-27T09:55:57Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 27/2/2009, a las 9:37, Sverre Rabbelier escribió:\n\n> Heya,\n>\n> On Fri, Feb 27, 2009 at 08:45, Caleb Cushing \n> wrote:\n>> git rebase -i seems a little more tedious/unfriendly than I'd like if\n>> all I want to do is edit HEAD~2 (assuming no merges) it's a bit of a\n>> pain to do a rebase -i and then pick which patches to edit. might be\n>> nice to be able to do stuff like git commit --amend and have\n>> that call rebase (as I think not rebasing is impossible?) with edit\n>> only on the ref I picked.\n>\n> Ah, yes, I would like this feature as well. But this could probably be\n> solved with a custom editor script that does a simple sed 's/pick\n> $TARGET/edit $TARGET/'?\n\nI'm not sure if this proposed feature would actually be very convenient.\n\nThink about the way \"git commit --amend\" currently works: it just \ntakes the current index and uses it to create a new commit, replacing \nthe current HEAD commit, and of course gives the user the opportunity \nto edit the commit message.\n\nIf you want to \"git commit --amend HEAD~2\" then how will you prepare \nyour index in a convenient fashion?\n\nThe way \"rebase -i\" works is to actually stop on the \"edit\" commit so \nthat you have an opportunity to tweak things in the index (or even \ncreate a _series_ of new commits). But giving the user a chance to \nedit _after_ doing \"git commit --amend HEAD~2\" would be a little \nsurprising seeing as \"git commit\" generally means \"create a commit \nobject right now\". And the user would then have to indicate that he/ \nshe was ready to go ahead and actually create the commit; and so you'd \nneed an ugly \"git commit --continue\" or similar to indicate that \nyou're done tweaking.\n\nAlternatively, you could say you don't care about the index and you \nonly want to edit the commit message. Then you'd be breaking with the \nexisting semantics of \"git commit --amend\" which _does_ pay attention \nto the state of the index.\n\nBasically, I think that the easiest workflow for doing what you want \nto do is actually just to use \"git rebase -i\". And if you have a very \nspecific special-case workflow that you want to automate then you \ncould indeed make a custom editor script, but it would have such a \nnarrow, specialized use that I'd question the value of it.\n\nCheers,\nWincent\n"},{"id":"106420","messageId":"alpine.DEB.1.00.0902271121590.6600@intel-tinevez-2-302","threadId":"18042","inReplyTo":"81bfc67a0902262345i63386076rbcf6d71ed88c29ac@mail.gmail.com","subject":"Re: FEATURE suggestion git commit --amend ","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-27T10:30:38Z","receivedAt":"2009-02-27T10:30:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 27 Feb 2009, Caleb Cushing wrote:\n\n> git rebase -i seems a little more tedious/unfriendly than I'd like if \n> all I want to do is edit HEAD~2 (assuming no merges) it's a bit of a \n> pain to do a rebase -i and then pick which patches to edit. might be \n> nice to be able to do stuff like git commit --amend and have that \n> call rebase (as I think not rebasing is impossible?) with edit only on \n> the ref I picked.\n> \n> hopefully I've explained well enough.\n\nYes, but IMHO you did not consider the undesired side effects well enough.\n\nFor example: What about merges?\n\nTo be clear: amending a merge is not just a matter of \"rebase -i \n^\" with a custom script, and even worse, there could be merges \nbetween the commit you want to amend and the current HEAD. That is a \ncomplete Pandora box right there.\n\nAlso, your amended changes could break reapplication of the later commits. \nSo \"git commit --amend \" is _semantically_ different \nfrom \"git commit --amend\".\n\nOf course, there is also the problem that might not be an ancestor \nof HEAD to begin with.\n\nAnd that the specified commit could be part of more than one branch, \nadding to user's confusion when it is only rewritten in the current \nbranch.\n\nBut more fundamental: is this operation something we want to make _that_ \neasy? After all, it is _not_ the common case, and it bears such a bunch \nof problems that the user should be made well aware of what she is doing.\n\nAll in all, as with many feature requests, I have to say that I see what \nyou want, but the side effects are too horrible -- and you did not \nconsider them, obviously, otherwise you would have put forward arguments \nas to why the side effects would not matter that much.\n\nCiao,\nDscho\n"},{"id":"106437","messageId":"49A7FD81.9070808@drmicha.warpmail.net","threadId":"18042","inReplyTo":"alpine.DEB.1.00.0902271121590.6600@intel-tinevez-2-302","subject":"Re: FEATURE suggestion git commit --amend ","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-02-27T14:49:37Z","receivedAt":"2009-02-27T14:49:37Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Schindelin venit, vidit, dixit 27.02.2009 11:30:\n> Hi,\n> \n> On Fri, 27 Feb 2009, Caleb Cushing wrote:\n> \n>> git rebase -i seems a little more tedious/unfriendly than I'd like if \n>> all I want to do is edit HEAD~2 (assuming no merges) it's a bit of a \n>> pain to do a rebase -i and then pick which patches to edit. might be \n>> nice to be able to do stuff like git commit --amend and have that \n>> call rebase (as I think not rebasing is impossible?) with edit only on \n>> the ref I picked.\n>>\n>> hopefully I've explained well enough.\n> \n> Yes, but IMHO you did not consider the undesired side effects well enough.\n> \n> For example: What about merges?\n> \n> To be clear: amending a merge is not just a matter of \"rebase -i \n> ^\" with a custom script, and even worse, there could be merges \n> between the commit you want to amend and the current HEAD. That is a \n> complete Pandora box right there.\n> \n> Also, your amended changes could break reapplication of the later commits. \n> So \"git commit --amend \" is _semantically_ different \n> from \"git commit --amend\".\n> \n> Of course, there is also the problem that might not be an ancestor \n> of HEAD to begin with.\n> \n> And that the specified commit could be part of more than one branch, \n> adding to user's confusion when it is only rewritten in the current \n> branch.\n> \n> But more fundamental: is this operation something we want to make _that_ \n> easy? After all, it is _not_ the common case, and it bears such a bunch \n> of problems that the user should be made well aware of what she is doing.\n> \n> All in all, as with many feature requests, I have to say that I see what \n> you want, but the side effects are too horrible -- and you did not \n> consider them, obviously, otherwise you would have put forward arguments \n> as to why the side effects would not matter that much.\n> \n> Ciao,\n> Dscho\n> \n\nFWIW I share all your caveats, especially the fact that - as you point\nout - we're really talking rebase here, not commit--amend.\n\nIn the end I think Caleb is asking for something like\n\ngit rebase --single $COMMIT\n\nto mean\n\nsha=$(git rev-parse --short $COMMIT)\nGIT_EDITOR='sed -i -e\"/'$sha'/s/pick/edit/\"' git rebase -i $COMMIT^\n\nwhich, again, is easy in shell, and left as an exercise regarding the\nimplementation as a git alias \"rebase-one\"...\n\nMichael\n"}]}