{"thread":{"id":"17183","subject":"[RFC PATCH] Make the rebase edit mode really end up in an edit state","startedAt":"2009-01-15T00:27:14Z","lastAt":"2009-01-18T01:24:18Z","messageCount":55,"participants":["Anders Melchiorsen","Junio C Hamano","Stephan Beyer","Johannes Schindelin","Boyd Stephen Smith Jr.","Miles Bader","Johannes Sixt","Johan Herland","Sverre Rabbelier","Adeodato Simó","Pieter de Bie","Björn Steinbrink","SZEDER Gábor","Wincent Colaiuta","Jay Soffian"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"100516","messageId":"87ab9th0rh.fsf@cup.kalibalik.dk","threadId":"17183","inReplyTo":null,"subject":"[RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Anders Melchiorsen","fromEmail":"mail@cup.kalibalik.dk","sentAt":"2009-01-15T00:27:14Z","receivedAt":"2009-01-15T00:27:14Z","isPatch":true,"sender":{"key":"mail@cup.kalibalik.dk","avatar":null},"body":"Previously, the interactive rebase edit mode placed the user after the\ncommit in question. That was awkward because a commit is supposedly\nimmutable. Thus, she was forced to use \"git commit --amend\" for her\nchanges.\n\nTo improve on this UI, we now issue \"git reset --soft HEAD^\" before\nexiting to the user. This puts the changes in the index, editable in\nthe Git sense. It also makes sure that a pre-filled editor is fired up\nwhen doing \"git rebase --continue\", in case the user just wanted to\nfix the commit message.\n\nThe revised UI is close to the situation in a merge/rebase conflict,\nand thus familiar to the user.\n\nSigned-off-by: Anders Melchiorsen \n---\n\n\nI always have a hard time figuring out what to do during an\ninteractive rebase. Recently, it dawned on me that the reason is that\nI have to do different things: one thing when editing on purpose, and\na different thing when resolving a conflict. So my fingers never learn.\n\nWith this change, I propose to make the UI more uniform. I think that\nthe new way is more intuitive, too, if you will agree that a Git UI\ncan be intuitive.\n\nAs I expect this to not be acceptable due to compatibility concerns, I\nhave not tested it much. The patch is mostly to catch some attention,\nbut I will be happy to complete it if there is interest in the change.\n\nIt was surprising for me to find the needed code already present. Now\nI know that I do not have to do \"git commit --amend\", it will happen\nautomatically if I add some files. That trick alone is worth the time\nthat I have spent on this :-).\n\n\nCheers,\nAnders.\n\n\n Documentation/git-rebase.txt | 10 ++++------\n git-rebase--interactive.sh | 29 ++++++++---------------------\n 2 files changed, 12 insertions(+), 27 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 32f0f12..3442a68 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -320,9 +320,8 @@ not look at them but at the commit names (\"deadbee\" and \"fa1afe1\" in this\n example), so do not delete or edit the names.\n \n By replacing the command \"pick\" with the command \"edit\", you can tell\n-'git-rebase' to stop after applying that commit, so that you can edit\n-the files and/or the commit message, amend the commit, and continue\n-rebasing.\n+'git-rebase' to stop after applying that commit. You are free to make\n+further modifications before you continue rebasing.\n \n If you want to fold two or more commits into one, replace the command\n \"pick\" with \"squash\" for the second and subsequent commit. If the\n@@ -375,9 +374,8 @@ add other commits. This can be used to split a commit into two:\n \n - Mark the commit you want to split with the action \"edit\".\n \n-- When it comes to editing that commit, execute `git reset HEAD^`. The\n- effect is that the HEAD is rewound by one, and the index follows suit.\n- However, the working tree stays the same.\n+- When it comes to editing that commit, execute `git reset`. The effect\n+ is that the changes in the commit are now only in the working tree.\n \n - Now add the changes to the index that you want to have in the first\n commit. You can use `git add` (possibly interactively) or\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex bdec43c..0fe678f 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -274,7 +274,7 @@ peek_next_command () {\n \n do_next () {\n \trm -f \"$DOTEST\"/message \"$DOTEST\"/author-script \\\n-\t\t\"$DOTEST\"/amend || exit\n+\t\t|| exit\n \tread command sha1 rest < \"$TODO\"\n \tcase \"$command\" in\n \t'#'*|'')\n@@ -294,13 +294,13 @@ do_next () {\n \t\tpick_one $sha1 ||\n \t\t\tdie_with_patch $sha1 \"Could not apply $sha1... $rest\"\n \t\tmake_patch $sha1\n-\t\tgit rev-parse --verify HEAD > \"$DOTEST\"/amend\n+\t\tgit reset --soft HEAD^ ||\n+\t\t\tdie \"Cannot rewind the HEAD\"\n \t\twarn \"Stopped at $sha1... $rest\"\n-\t\twarn \"You can amend the commit now, with\"\n \t\twarn\n-\t\twarn \"\tgit commit --amend\"\n-\t\twarn\n-\t\twarn \"Once you are satisfied with your changes, run\"\n+\t\twarn \"You can edit the commit now. When you are satisfied,\"\n+\t\twarn \"mark the corrected paths with 'git add ', and\"\n+\t\twarn \"then run\"\n \t\twarn\n \t\twarn \"\tgit rebase --continue\"\n \t\twarn\n@@ -442,22 +442,9 @@ do\n \t\telse\n \t\t\t. \"$DOTEST\"/author-script ||\n \t\t\t\tdie \"Cannot find the author identity\"\n-\t\t\tamend=\n-\t\t\tif test -f \"$DOTEST\"/amend\n-\t\t\tthen\n-\t\t\t\tamend=$(git rev-parse --verify HEAD)\n-\t\t\t\ttest \"$amend\" = $(cat \"$DOTEST\"/amend) ||\n-\t\t\t\tdie \"\\\n-You have uncommitted changes in your working tree. Please, commit them\n-first and then run 'git rebase --continue' again.\"\n-\t\t\t\tgit reset --soft HEAD^ ||\n-\t\t\t\tdie \"Cannot rewind the HEAD\"\n-\t\t\tfi\n \t\t\texport GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&\n-\t\t\tgit commit --no-verify -F \"$DOTEST\"/message -e || {\n-\t\t\t\ttest -n \"$amend\" && git reset --soft $amend\n+\t\t\tgit commit --no-verify -F \"$DOTEST\"/message -e ||\n \t\t\t\tdie \"Could not commit staged changes.\"\n-\t\t\t}\n \t\tfi\n \n \t\trequire_clean_work_tree\n@@ -590,7 +577,7 @@ first and then run 'git rebase --continue' again.\"\n #\n # Commands:\n # p, pick = use commit\n-# e, edit = use commit, but stop for amending\n+# e, edit = use commit, but stop for editing\n # s, squash = use commit, but meld into previous commit\n #\n # If you remove a line here THAT COMMIT WILL BE LOST.\n-- \n1.6.0.2.514.g23abd3\n"},{"id":"100522","messageId":"7vfxjlxuu5.fsf@gitster.siamese.dyndns.org","threadId":"17183","inReplyTo":"87ab9th0rh.fsf@cup.kalibalik.dk","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-15T00:43:14Z","receivedAt":"2009-01-15T00:43:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Anders Melchiorsen writes:\n\n> I always have a hard time figuring out what to do during an\n> interactive rebase. Recently, it dawned on me that the reason is that\n> I have to do different things: one thing when editing on purpose, and\n> a different thing when resolving a conflict. So my fingers never learn.\n>\n> With this change, I propose to make the UI more uniform. I think that\n> the new way is more intuitive, too, if you will agree that a Git UI\n> can be intuitive.\n>\n> As I expect this to not be acceptable due to compatibility concerns, I\n> have not tested it much. The patch is mostly to catch some attention,\n> but I will be happy to complete it if there is interest in the change.\n>\n> It was surprising for me to find the needed code already present. Now\n> I know that I do not have to do \"git commit --amend\", it will happen\n> automatically if I add some files. That trick alone is worth the time\n> that I have spent on this :-).\n\nWe may need a version bump to 1.7.0 to update the UI for this command, but \nplease do test rigorously to build a stronger case for a saner UI.\n\nI've always had trouble with the instruction we give for splitting one\ncommit into two using the interactive rebase in the documentation, as it\nalways had a strong \"Huh?\" effect on me when it suddenly starts talking\nabout doing a \"git reset HEAD^\"; I suspect your change may improve this\nsituation quite a bit.\n"},{"id":"100524","messageId":"20090115004902.GE32313@leksak.fem-net","threadId":"17183","inReplyTo":"87ab9th0rh.fsf@cup.kalibalik.dk","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2009-01-15T00:49:02Z","receivedAt":"2009-01-15T00:49:02Z","isPatch":true,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nAnders Melchiorsen wrote:\n> As I expect this to not be acceptable due to compatibility concerns, I\n> have not tested it much. The patch is mostly to catch some attention,\n> but I will be happy to complete it if there is interest in the change.\n\nI think I like it and I think it's not the first time this comes up on\nthe list. (Not sure, and too lazy to grab the archives.)\n\nAlso, in the design process of \"git-sequencer\" we (at least my mentors\nand I) discussed about doing this (\"edit\" vs \"pause\"), too, but it is\nalways bad to change behavior many people are used, too.\nBut sequencer instructions support options. So this could be solved as\nan option for \"edit\", e.g. \"edit --no-commit\" (or \"edit -n\").\n\nSo I'm writing this on my TODO list for the time after sequencer is\nmerged into git...\n\nRegards,\n Stephan\n\n-- \nStephan Beyer , PGP 0x6EDDD207FCC5040F\n"},{"id":"100525","messageId":"alpine.DEB.1.00.0901150149130.3586@pacific.mpi-cbg.de","threadId":"17183","inReplyTo":"87ab9th0rh.fsf@cup.kalibalik.dk","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T00:53:01Z","receivedAt":"2009-01-15T00:53:01Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Anders Melchiorsen wrote:\n\n> Previously, the interactive rebase edit mode placed the user after the \n> commit in question. That was awkward because a commit is supposedly \n> immutable. Thus, she was forced to use \"git commit --amend\" for her \n> changes.\n\nMaybe, maybe not. I frequently rebase with \"edit\" when I actually mean \n\"stop\" (but \"s\" was taken from \"squash\" already). Then I test things, \npossibly fixing them.\n\nSo in that case, I do not want a git reset --soft HEAD^.\n\nIn any case, there is a pretty obvious difference between a merge conflict \nand a stop at \"edit\": the latter even shows you a pretty verbose \nexplanation what to do next.\n\nI also have to admit that it escapes me why you would want to force a new \ncommit if nothing was changed to begin with.\n\nHowever, I often would like to have \"amend message\" or some such, and I \nremember having seen patches, but I do not remember why they did not make \nit in.\n\nCiao,\nDscho\n"},{"id":"100536","messageId":"200901142049.54775.bss@iguanasuicide.net","threadId":"17183","inReplyTo":"7vfxjlxuu5.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2009-01-15T02:49:50Z","receivedAt":"2009-01-15T02:49:50Z","isPatch":true,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Wednesday 14 January 2009, Junio C Hamano wrote \nabout 'Re: [RFC PATCH] Make the rebase edit mode really end up in an edit \nstate':\n>Anders Melchiorsen writes:\n>> I always have a hard time figuring out what to do during an\n>> interactive rebase. Recently, it dawned on me that the reason is that\n>> I have to do different things: one thing when editing on purpose, and\n>> a different thing when resolving a conflict.\n>>\n>> With this change, I propose to make the UI more uniform. I think that\n>> the new way is more intuitive, too, if you will agree that a Git UI\n>> can be intuitive.\n>>\n>> I expect this to not be acceptable due to compatibility concerns.\n>\n>We may need a version bump to 1.7.0 to update the UI for this command,\n> but please do test rigorously to build a stronger case for a saner UI.\n\nInstead of changing the meaning of edit, how about introducing a \"replace\" \ncommand?\n-- \nBoyd Stephen Smith Jr. ,= ,-_-. =. \nbss@iguanasuicide.net ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' \nhttp://iguanasuicide.net/ \\_/ \n"},{"id":"100543","messageId":"buo8wpdfbv9.fsf@dhapc248.dev.necel.com","threadId":"17183","inReplyTo":"200901142049.54775.bss@iguanasuicide.net","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2009-01-15T04:10:18Z","receivedAt":"2009-01-15T04:10:18Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"\"Boyd Stephen Smith Jr.\" writes:\n>>We may need a version bump to 1.7.0 to update the UI for this command,\n>> but please do test rigorously to build a stronger case for a saner UI.\n>\n> Instead of changing the meaning of edit, how about introducing a \"replace\" \n> command?\n\nThat seems like at best an awkward workaround, not a real solution to\nthe problem, which is that the term \"edit XXXX\" suggests you're starting\nwith XXXX and modifying it. The term \"replace\" by contrast, seems more\nto connote entirely removing XXXX and substituting something else.\n\n[I do wonder how on earth the current awkward behavior was accepted in\nthe first place...]\n\n-Miles\n\n-- \n\"Most attacks seem to take place at night, during a rainstorm, uphill,\n where four map sheets join.\" -- Anon. British Officer in WW I\n"},{"id":"100545","messageId":"200901142300.31718.bss@iguanasuicide.net","threadId":"17183","inReplyTo":"buo8wpdfbv9.fsf@dhapc248.dev.necel.com","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2009-01-15T05:00:26Z","receivedAt":"2009-01-15T05:00:26Z","isPatch":true,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Wednesday 14 January 2009, Miles Bader wrote about 'Re: \n[RFC PATCH] Make the rebase edit mode really end up in an edit state':\n>\"Boyd Stephen Smith Jr.\" writes:\n>>>We may need a version bump to 1.7.0 to update the UI for this command,\n>>> but please do test rigorously to build a stronger case for a saner UI.\n>>\n>> Instead of changing the meaning of edit, how about introducing a\n>> \"replace\" command?\n>\n>That seems like at best an awkward workaround, not a real solution to\n>the problem,\n\nActually, I think it's a better solution (or rather a solution to the real \nproblem) because others have already said they like and expect the current \nedit behavior.\n\nThe \"real problem\" is you need different behavior for your interactive \nrebasing.\n\n>which is that the term \"edit XXXX\" suggests you're starting \n>with XXXX and modifying it.\n\nExactly. \"edit\" is: While interactively rebuilding history (rebase -i), you \nget to the first place that commit existed and then modify it \n(commit --amend or other tools).\n\n>The term \"replace\" by contrast, seems more \n>to connote entirely removing XXXX and substituting something else.\n\nExactly. \"replace\" is: While rebasing you stop just before the commit \nexisted (changes are even staged) and decide to do something else (like \nusing add -i and a few commit commands to split the thing up or whatever).\n\n>[I do wonder how on earth the current awkward behavior was accepted in\n>the first place...]\n\n(Actually, I do too, but it's accepted and expected behavior now--good \nreason not to change it.)\n-- \nBoyd Stephen Smith Jr. ,= ,-_-. =. \nbss@iguanasuicide.net ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' \nhttp://iguanasuicide.net/ \\_/ \n"},{"id":"100546","messageId":"7v1vv5w0zt.fsf@gitster.siamese.dyndns.org","threadId":"17183","inReplyTo":"buo8wpdfbv9.fsf@dhapc248.dev.necel.com","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-15T06:13:10Z","receivedAt":"2009-01-15T06:13:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader writes:\n\n> [I do wonder how on earth the current awkward behavior was accepted in\n> the first place...]\n\nThat's actually very easy to explain. Both the contributor and the\nmaintainer were rather familiar with the workflow using tools before\n\"rebase -i\" appeared, and to them, editing an existing commit was\nequivalent to first plant yourself on the commit to be amended, issue\n\"commit --amend\", and continue on with other tasks (similarly, \"picking\" an\nexisting commit is to cherry-pick the commit to the state whatever the\nprevious sequence of commands left). In other words, they both thought in\nterms of the underlying command sequence and it did not appear unnatural\nat all to them.\n"},{"id":"100548","messageId":"496EE74F.6000205@viscovery.net","threadId":"17183","inReplyTo":"alpine.DEB.1.00.0901150149130.3586@pacific.mpi-cbg.de","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-01-15T07:35:43Z","receivedAt":"2009-01-15T07:35:43Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin schrieb:\n> On Thu, 15 Jan 2009, Anders Melchiorsen wrote:\n>> Previously, the interactive rebase edit mode placed the user after the \n>> commit in question. That was awkward because a commit is supposedly \n>> immutable. Thus, she was forced to use \"git commit --amend\" for her \n>> changes.\n> \n> Maybe, maybe not. I frequently rebase with \"edit\" when I actually mean \n> \"stop\" (but \"s\" was taken from \"squash\" already). Then I test things, \n> possibly fixing them.\n> \n> So in that case, I do not want a git reset --soft HEAD^.\n\nAbsolutely! I use \"edit\" for this purpose as well quite frequently.\n\n-- Hannes\n"},{"id":"100555","messageId":"200901151101.53441.johan@herland.net","threadId":"17183","inReplyTo":"496EE74F.6000205@viscovery.net","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-01-15T10:01:53Z","receivedAt":"2009-01-15T10:01:53Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Thursday 15 January 2009, Johannes Sixt wrote:\n> Johannes Schindelin schrieb:\n> > On Thu, 15 Jan 2009, Anders Melchiorsen wrote:\n> >> Previously, the interactive rebase edit mode placed the user after the\n> >> commit in question. That was awkward because a commit is supposedly\n> >> immutable. Thus, she was forced to use \"git commit --amend\" for her\n> >> changes.\n> >\n> > Maybe, maybe not. I frequently rebase with \"edit\" when I actually mean\n> > \"stop\" (but \"s\" was taken from \"squash\" already). Then I test things,\n> > possibly fixing them.\n> >\n> > So in that case, I do not want a git reset --soft HEAD^.\n>\n> Absolutely! I use \"edit\" for this purpose as well quite frequently.\n\nWhat about providing both options?\n\n\"modify\" does the \"git reset --soft HEAD^\" (Anders' suggestion)\n\"amend\" requires a \"git commit --amend\" (current behaviour)\n\"edit\" == \"amend\", but is deprecated and goes away in the future\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"100559","messageId":"bd6139dc0901150352t2d2fa388x3eb842bbc8c4baa6@mail.gmail.com","threadId":"17183","inReplyTo":"200901151101.53441.johan@herland.net","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-15T11:52:20Z","receivedAt":"2009-01-15T11:52:20Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Jan 15, 2009 at 11:01, Johan Herland wrote:\n> \"modify\" does the \"git reset --soft HEAD^\" (Anders' suggestion)\n> \"amend\" requires a \"git commit --amend\" (current behaviour)\n\nWhy have amend do the same as edit? If you add an 'amend' one instead\nmake it drop you into an editor to change the commit message. That's a\nworkflow I often use. Often times I do not have a proper commit\nmessage when I commit (sometimes it is the result of \"git commit -a -m\n\"tmp\"). To me having an 'amend' command that allows one to edit the\ncommit message would make sense a lot :).\n\n> \"edit\" == \"amend\", but is deprecated and goes away in the future\n\nAnd as such, have edit do what it currently does.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"100560","messageId":"alpine.DEB.1.00.0901151323290.3586@pacific.mpi-cbg.de","threadId":"17183","inReplyTo":"buo8wpdfbv9.fsf@dhapc248.dev.necel.com","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T12:24:11Z","receivedAt":"2009-01-15T12:24:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Miles Bader wrote:\n\n> [I do wonder how on earth the current awkward behavior was accepted in \n> the first place...]\n\nThanks for the praise! It is always nice to hear that one's work is \nappreciated.\n"},{"id":"100561","messageId":"alpine.DEB.1.00.0901151325310.3586@pacific.mpi-cbg.de","threadId":"17183","inReplyTo":"bd6139dc0901150352t2d2fa388x3eb842bbc8c4baa6@mail.gmail.com","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T12:36:10Z","receivedAt":"2009-01-15T12:36:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Sverre Rabbelier wrote:\n\n> On Thu, Jan 15, 2009 at 11:01, Johan Herland wrote:\n> > \"modify\" does the \"git reset --soft HEAD^\" (Anders' suggestion)\n\nI could live with \"modify\".\n\n> > \"amend\" requires a \"git commit --amend\" (current behaviour)\n> \n> Why have amend do the same as edit? If you add an 'amend' one instead\n> make it drop you into an editor to change the commit message. That's a\n> workflow I often use. Often times I do not have a proper commit\n> message when I commit (sometimes it is the result of \"git commit -a -m\n> \"tmp\"). To me having an 'amend' command that allows one to edit the\n> commit message would make sense a lot :).\n> \n> > \"edit\" == \"amend\", but is deprecated and goes away in the future\n> \n> And as such, have edit do what it currently does.\n\nFWIW I fully agree.\n\nIf at all, I'd introduce 'examine' as a synonym to 'edit' (might be more \nintuitive).\n\nHowever, for the same reason (is it intuitive?) I am not fully convinced \nof 'amend' either. Because --amend _can_ mean that you change the \ndiff of the commit. Maybe 'correct', 'redact' or 'rephrase'?\n\nBTW I was not fully happy with 'edit' back then, either, which is the \nreason why I showed the usage in the comment _above_ the commit list. But \nnobody could suggest a name that I found convincingly better.\n\nCiao,\nDscho\n"},{"id":"100563","messageId":"20090115124433.GA4484@chistera.yi.org","threadId":"17183","inReplyTo":"alpine.DEB.1.00.0901151325310.3586@pacific.mpi-cbg.de","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Adeodato Simó","fromEmail":"dato@net.com.org.es","sentAt":"2009-01-15T12:44:33Z","receivedAt":"2009-01-15T12:44:33Z","isPatch":true,"sender":{"key":"dato@net.com.org.es","avatar":"https://gravatar.com/avatar/952ec7d5d5663eb8baf631b5c37f9c58480a881920dd5f8a2d3a71f969b72b53?d=mp&s=160"},"body":"* Johannes Schindelin [Thu, 15 Jan 2009 13:36:10 +0100]:\n\n> However, for the same reason (is it intuitive?) I am not fully convinced \n> of 'amend' either. Because --amend _can_ mean that you change the \n> diff of the commit.\n\nRight.\n\n> Maybe 'correct', 'redact' or 'rephrase'?\n\neditmsg?\n\n-- \nAdeodato Simó dato at net.com.org.es\nDebian Developer adeodato at debian.org\n \nHe who has not a good memory should never take upon himself the trade of lying.\n -- Michel de Montaigne\n"},{"id":"100564","messageId":"bd6139dc0901150445l51f3b861n5bbd85bb6d1382b6@mail.gmail.com","threadId":"17183","inReplyTo":"alpine.DEB.1.00.0901151325310.3586@pacific.mpi-cbg.de","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-15T12:45:46Z","receivedAt":"2009-01-15T12:45:46Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Jan 15, 2009 at 13:36, Johannes Schindelin\n wrote:\n> If at all, I'd introduce 'examine' as a synonym to 'edit' (might be more\n> intuitive).\n\nExamine suggests that you cannot change the commit (you can look, but\ndon't touch it!), no?\n\n> However, for the same reason (is it intuitive?) I am not fully convinced\n> of 'amend' either. Because --amend _can_ mean that you change the\n> diff of the commit. Maybe 'correct', 'redact' or 'rephrase'?\n\nOTOH, when you have no changes staged \"git commit --ammend\" will do\nexactly that, it will let you edit the commit message of the last\ncommit.\n\n> BTW I was not fully happy with 'edit' back then, either, which is the\n> reason why I showed the usage in the comment _above_ the commit list. But\n> nobody could suggest a name that I found convincingly better.\n\nThe coder's law #349: \"The hardest part of writing new functionality\nis coming up with a proper name that everyone agrees on\".\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"100574","messageId":"19A8FAC6-A27A-4D6B-A276-02EE17F0E5F5@frim.nl","threadId":"17183","inReplyTo":"alpine.DEB.1.00.0901151325310.3586@pacific.mpi-cbg.de","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Pieter de Bie","fromEmail":"pieter@frim.nl","sentAt":"2009-01-15T12:52:54Z","receivedAt":"2009-01-15T12:52:54Z","isPatch":true,"sender":{"key":"pieter@frim.nl","avatar":null},"body":"\nOn Jan 15, 2009, at 12:36 PM, Johannes Schindelin wrote:\n\n> If at all, I'd introduce 'examine' as a synonym to 'edit' (might be \n> more\n> intuitive).\n>\n> However, for the same reason (is it intuitive?) I am not fully \n> convinced\n> of 'amend' either. Because --amend _can_ mean that you change the\n> diff of the commit. Maybe 'correct', 'redact' or 'rephrase'?\n\nI think this demonstrates that you can do a lot more with 'edit' than \njust edit.\n'redact' etc also don't cover it. Perhaps just a general 'pause' or \nsomething?\n\nYou can then put something like 'pause -- pause, for example to \namend commit'\nin the description part.\n"},{"id":"100566","messageId":"bd6139dc0901150455i3a978f9co3fd938c03a788a78@mail.gmail.com","threadId":"17183","inReplyTo":"19A8FAC6-A27A-4D6B-A276-02EE17F0E5F5@frim.nl","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-15T12:55:09Z","receivedAt":"2009-01-15T12:55:09Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Jan 15, 2009 at 13:52, Pieter de Bie wrote:\n> I think this demonstrates that you can do a lot more with 'edit' than just\n> edit.\n> 'redact' etc also don't cover it. Perhaps just a general 'pause' or\n> something?\n>\n> You can then put something like 'pause -- pause, for example to amend\n> commit'\n> in the description part.\n\nThat makes sense, perhaps we could name the feature described by the\nOP something like \"reset\", as that is what it actually does?\n\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"100573","messageId":"8B5B7148-B900-4E01-9B2C-16C251966F7F@frim.nl","threadId":"17183","inReplyTo":"alpine.DEB.1.00.0901151325310.3586@pacific.mpi-cbg.de","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Pieter de Bie","fromEmail":"pieter@frim.nl","sentAt":"2009-01-15T12:57:04Z","receivedAt":"2009-01-15T12:57:04Z","isPatch":true,"sender":{"key":"pieter@frim.nl","avatar":null},"body":"\nOn Jan 15, 2009, at 12:36 PM, Johannes Schindelin wrote:\n\n> BTW I was not fully happy with 'edit' back then, either, which is the\n> reason why I showed the usage in the comment _above_ the commit \n> list. But\n> nobody could suggest a name that I found convincingly better.\n\n(BTW, I reply to this thread because I'm also often confused with the\nrebase. The thing that hits me most is that with resolving conflicts,\nyou have to do a 'git commit' and with 'edit', you have to do a 'git\ncommit --amend'. This can get confusing if you set up an interactive\nrebase where you have some new picks or squashes, and also an edit.\nIf the rebase stops, you first have to carefully read whether you're\nsupposed to do a 'git commit' or a 'git commit --amend', and remember\nthat until you're finished with the changes).\n\n- Pieter\n"},{"id":"100580","messageId":"alpine.DEB.1.00.0901151440380.3586@pacific.mpi-cbg.de","threadId":"17183","inReplyTo":"20090115124433.GA4484@chistera.yi.org","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T13:41:14Z","receivedAt":"2009-01-15T13:41:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Adeodato Simó wrote:\n\n> editmsg?\n\nHas the same first letter as 'edit'. Would be confusing with the shortcut \n'e', no?\n\nCiao,\nDscho\n"},{"id":"100581","messageId":"bd6139dc0901150541o491ee9b8n1b5f3540a924b89e@mail.gmail.com","threadId":"17183","inReplyTo":"alpine.DEB.1.00.0901151440380.3586@pacific.mpi-cbg.de","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-15T13:41:31Z","receivedAt":"2009-01-15T13:41:31Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Jan 15, 2009 at 14:41, Johannes Schindelin\n wrote:\n> On Thu, 15 Jan 2009, Adeodato Simó wrote:\n>> editmsg?\n>\n> Has the same first letter as 'edit'. Would be confusing with the shortcut\n> 'e', no?\n\n\"msgedit\" with shortcut 'm'?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"100582","messageId":"alpine.DEB.1.00.0901151442230.3586@pacific.mpi-cbg.de","threadId":"17183","inReplyTo":"bd6139dc0901150445l51f3b861n5bbd85bb6d1382b6@mail.gmail.com","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T13:42:47Z","receivedAt":"2009-01-15T13:42:47Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Sverre Rabbelier wrote:\n\n> On Thu, Jan 15, 2009 at 13:36, Johannes Schindelin\n> wrote:\n> > If at all, I'd introduce 'examine' as a synonym to 'edit' (might be more\n> > intuitive).\n> \n> Examine suggests that you cannot change the commit (you can look, but\n> don't touch it!), no?\n\nSo if you want to look but don't touch it, you can do exactly that. \nBrilliant, isn't it?\n\nCiao,\nDscho\n"},{"id":"100583","messageId":"20090115134345.GA7173@chistera.yi.org","threadId":"17183","inReplyTo":"alpine.DEB.1.00.0901151440380.3586@pacific.mpi-cbg.de","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Adeodato Simó","fromEmail":"dato@net.com.org.es","sentAt":"2009-01-15T13:43:45Z","receivedAt":"2009-01-15T13:43:45Z","isPatch":true,"sender":{"key":"dato@net.com.org.es","avatar":"https://gravatar.com/avatar/952ec7d5d5663eb8baf631b5c37f9c58480a881920dd5f8a2d3a71f969b72b53?d=mp&s=160"},"body":"* Johannes Schindelin [Thu, 15 Jan 2009 14:41:14 +0100]:\n\n> Hi,\n\n> On Thu, 15 Jan 2009, Adeodato Simó wrote:\n\n> > editmsg?\n\n> Has the same first letter as 'edit'. Would be confusing with the shortcut \n> 'e', no?\n\nYes, you are right. I always write the full word myself, so I forgot\nabbreviations are supported and commonly used.\n\n-- \nAdeodato Simó dato at net.com.org.es\nDebian Developer adeodato at debian.org\n \nA lie can go round the world before the truth has got its boots on.\n -- Terry Pratchett\n"},{"id":"100584","messageId":"20090115134612.GA6556@atjola.homenet","threadId":"17183","inReplyTo":"8B5B7148-B900-4E01-9B2C-16C251966F7F@frim.nl","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-01-15T13:46:12Z","receivedAt":"2009-01-15T13:46:12Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.01.15 12:57:04 +0000, Pieter de Bie wrote:\n>\n> On Jan 15, 2009, at 12:36 PM, Johannes Schindelin wrote:\n>\n>> BTW I was not fully happy with 'edit' back then, either, which is the\n>> reason why I showed the usage in the comment _above_ the commit list. \n>> But\n>> nobody could suggest a name that I found convincingly better.\n>\n> (BTW, I reply to this thread because I'm also often confused with the\n> rebase. The thing that hits me most is that with resolving conflicts,\n> you have to do a 'git commit' and with 'edit', you have to do a 'git\n> commit --amend'. This can get confusing if you set up an interactive\n> rebase where you have some new picks or squashes, and also an edit.\n> If the rebase stops, you first have to carefully read whether you're\n> supposed to do a 'git commit' or a 'git commit --amend', and remember\n> that until you're finished with the changes).\n\nYou can handle both cases with:\ngit add -u # Or whatever\ngit rebase --continue\n\nOnly when you split a commit, you have to explicitly reset and commit.\n\nBjörn\n"},{"id":"100585","messageId":"200901151454.30670.johan@herland.net","threadId":"17183","inReplyTo":"bd6139dc0901150352t2d2fa388x3eb842bbc8c4baa6@mail.gmail.com","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-01-15T13:54:30Z","receivedAt":"2009-01-15T13:54:30Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Thursday 15 January 2009, Sverre Rabbelier wrote:\n> On Thu, Jan 15, 2009 at 11:01, Johan Herland wrote:\n> > \"modify\" does the \"git reset --soft HEAD^\" (Anders' suggestion)\n> > \"amend\" requires a \"git commit --amend\" (current behaviour)\n>\n> Why have amend do the same as edit?\n\nThe names I chose are somewhat arbitrary, since we obviously have to \nkeep on bikeshedding until we have something everybody can agree to.\n\nHowever, my rationale was that IMO the word \"edit\" more closely matches \nAnders' suggestion, and is therefore somewhat misleading as a \ndescription of the current behaviour. But we obviously cannot change \nthe meaning of \"edit\" without upsetting current users. Therefore, \nintroduce \"amend\" to more accurately describe the current behaviour. As \nfor \"modify\", it was simply the best synonym for \"edit\" I could find.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"100587","messageId":"bd6139dc0901150556q674faf80w8891b50addc982@mail.gmail.com","threadId":"17183","inReplyTo":"alpine.DEB.1.00.0901151442230.3586@pacific.mpi-cbg.de","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-15T13:56:22Z","receivedAt":"2009-01-15T13:56:22Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Jan 15, 2009 at 14:42, Johannes Schindelin\n wrote:\n> So if you want to look but don't touch it, you can do exactly that.\n> Brilliant, isn't it?\n\nYes, ofcourse, but the current edit does allow you to modify (with\n'git commit --amend')...\nI agree with Johan Herland though, Bikeshedding ftw :).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"100588","messageId":"20090115135716.GC10045@leksak.fem-net","threadId":"17183","inReplyTo":"bd6139dc0901150541o491ee9b8n1b5f3540a924b89e@mail.gmail.com","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2009-01-15T13:57:16Z","receivedAt":"2009-01-15T13:57:16Z","isPatch":true,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nSverre Rabbelier wrote:\n> >> editmsg?\n> >\n> > Has the same first letter as 'edit'. Would be confusing with the shortcut\n> > 'e', no?\n> \n> \"msgedit\" with shortcut 'm'?\n\n*sigh* If I was just not so late with sequencer...\n\nThere it is \"pick -e\" (or \"pick --edit\").\n\nRegards,\n Stephan\n\n-- \nStephan Beyer , PGP 0x6EDDD207FCC5040F\n"},{"id":"100592","messageId":"alpine.DEB.1.00.0901151501400.3586@pacific.mpi-cbg.de","threadId":"17183","inReplyTo":"20090115135716.GC10045@leksak.fem-net","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T14:02:06Z","receivedAt":"2009-01-15T14:02:06Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Stephan Beyer wrote:\n\n> Sverre Rabbelier wrote:\n> > >> editmsg?\n> > >\n> > > Has the same first letter as 'edit'. Would be confusing with the shortcut\n> > > 'e', no?\n> > \n> > \"msgedit\" with shortcut 'm'?\n> \n> *sigh* If I was just not so late with sequencer...\n> \n> There it is \"pick -e\" (or \"pick --edit\").\n\n... which obviously shares all the shortcomings of \"edit\".\n\nCiao,\nDscho\n"},{"id":"100620","messageId":"20090115153529.GA13961@neumann","threadId":"17183","inReplyTo":"7vfxjlxuu5.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2009-01-15T15:35:29Z","receivedAt":"2009-01-15T15:35:29Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Wed, Jan 14, 2009 at 04:43:14PM -0800, Junio C Hamano wrote:\n> I've always had trouble with the instruction we give for splitting one\n> commit into two using the interactive rebase in the documentation, as it\n> always had a strong \"Huh?\" effect on me when it suddenly starts talking\n> about doing a \"git reset HEAD^\"; I suspect your change may improve this\n> situation quite a bit.\n\nI think we might want do differentiate editing a commit (modifying\neither the commit message or the patch or both) or splitting a commit.\n\nThe first is served well with the current 'edit' rebase command IMHO.\nI don't really see the point of the additional 'git reset --soft\nHEAD^'.\n\n * If you want to edit the commit message only, then you are\n better off with 'git commit --amend', because it preserves the\n previous commit message. But with 'git reset --soft HEAD^' and\n 'git commit' the commit message is \"lost\"; you have to use 'git\n commit -c ORIG_HEAD' instead, which is not that straightforward\n (and we don't have completion support for it).\n\n * If you want to modify the patch, too, then you would have to use\n 'git add' anyway, regardless of whether there was a 'git reset\n --soft HEAD^', or not. The only benefit of that 'reset' I'm seeing\n is that in that case 'git diff --cached' would show all the changes\n that would be committed; without the 'reset' 'git diff --cached\n HEAD^' is needed.\n\n But I'm not sure whether that benefit would offset the confusion of\n one more rebase command with just slightly different meaning.\n\nFor the second we could introduce a new rebase command like 'split',\nwhich would do the same as 'edit' but would also perform that 'git\nreset HEAD^' mentioned in the documentation automatically. Or perhaps\nit could be called 'divide', since the 's' abbreviation for 'split' is\nalready taken by 'squash'. (Or maybe use capital 'S' for 'split'?\nmight be confusing...)\n\n\nRegards,\nGábor\n"},{"id":"100633","messageId":"7vmydsv72u.fsf@gitster.siamese.dyndns.org","threadId":"17183","inReplyTo":"bd6139dc0901150445l51f3b861n5bbd85bb6d1382b6@mail.gmail.com","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-15T16:59:21Z","receivedAt":"2009-01-15T16:59:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sverre Rabbelier\" writes:\n\n> On Thu, Jan 15, 2009 at 13:36, Johannes Schindelin\n> wrote:\n>> If at all, I'd introduce 'examine' as a synonym to 'edit' (might be more\n>> intuitive).\n>\n> Examine suggests that you cannot change the commit (you can look, but\n> don't touch it!), no?\n\n'stop' would be closest to what it currently does. It stops and it is up\nto you how to screw up the result ;-).\n"},{"id":"100636","messageId":"bd6139dc0901150916v41959d78r41483617b952ed5f@mail.gmail.com","threadId":"17183","inReplyTo":"7vmydsv72u.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-15T17:16:29Z","receivedAt":"2009-01-15T17:16:29Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Jan 15, 2009 at 17:59, Junio C Hamano wrote:\n> 'stop' would be closest to what it currently does. It stops and it is up\n> to you how to screw up the result ;-).\n\nHmmm, yes, I think that would be a better alias; but I think I like\nthe idea to wait for changes like this till sequencer goes in, mhh?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"100641","messageId":"alpine.DEB.1.00.0901151921040.3586@pacific.mpi-cbg.de","threadId":"17183","inReplyTo":"7vmydsv72u.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T18:21:16Z","receivedAt":"2009-01-15T18:21:16Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Junio C Hamano wrote:\n\n> \"Sverre Rabbelier\" writes:\n> \n> > On Thu, Jan 15, 2009 at 13:36, Johannes Schindelin\n> > wrote:\n> >> If at all, I'd introduce 'examine' as a synonym to 'edit' (might be more\n> >> intuitive).\n> >\n> > Examine suggests that you cannot change the commit (you can look, but\n> > don't touch it!), no?\n> \n> 'stop' would be closest to what it currently does. It stops and it is up\n> to you how to screw up the result ;-).\n\nBut it shares the first letter with 'squash'.\n\nCiao,\nDscho\n"},{"id":"100644","messageId":"200901151946.04991.johan@herland.net","threadId":"17183","inReplyTo":"alpine.DEB.1.00.0901151921040.3586@pacific.mpi-cbg.de","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-01-15T18:46:04Z","receivedAt":"2009-01-15T18:46:04Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Thursday 15 January 2009, Johannes Schindelin wrote:\n> On Thu, 15 Jan 2009, Junio C Hamano wrote:\n> > 'stop' would be closest to what it currently does. It stops and it\n> > is up to you how to screw up the result ;-).\n>\n> But it shares the first letter with 'squash'.\n\nPersonally, I'd rather use \"pause\", but that is taken as well.\n\nOther suggestions:\n\nwait\nyield\nrest\ntimeout\n\n\n..Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"100645","messageId":"87ocy8flka.fsf@cup.kalibalik.dk","threadId":"17183","inReplyTo":"200901151946.04991.johan@herland.net","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Anders Melchiorsen","fromEmail":"mail@cup.kalibalik.dk","sentAt":"2009-01-15T18:53:09Z","receivedAt":"2009-01-15T18:53:09Z","isPatch":true,"sender":{"key":"mail@cup.kalibalik.dk","avatar":null},"body":"Johan Herland writes:\n\n> On Thursday 15 January 2009, Johannes Schindelin wrote:\n>> On Thu, 15 Jan 2009, Junio C Hamano wrote:\n>> > 'stop' would be closest to what it currently does. It stops and it\n>> > is up to you how to screw up the result ;-).\n>>\n>> But it shares the first letter with 'squash'.\n>\n> Personally, I'd rather use \"pause\", but that is taken as well.\n>\n> Other suggestions:\n>\n> wait\n> yield\n> rest\n> timeout\n\nbreak\n\n\n\nAnders.\n"},{"id":"100648","messageId":"8035E52E-D202-4C42-BDFD-DC7A925580A3@wincent.com","threadId":"17183","inReplyTo":"200901151946.04991.johan@herland.net","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-01-15T19:27:49Z","receivedAt":"2009-01-15T19:27:49Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 15/1/2009, a las 19:46, Johan Herland escribió:\n\n> On Thursday 15 January 2009, Johannes Schindelin wrote:\n>> On Thu, 15 Jan 2009, Junio C Hamano wrote:\n>>> 'stop' would be closest to what it currently does. It stops and it\n>>> is up to you how to screw up the result ;-).\n>>\n>> But it shares the first letter with 'squash'.\n>\n> Personally, I'd rather use \"pause\", but that is taken as well.\n>\n> Other suggestions:\n>\n> wait\n> yield\n> rest\n> timeout\n\nPerhaps stating the obvious, but:\n\nwait - best suggestion so far, seeing as we can't use \"stop\"\n\nyield - might sound intuitive to a Ruby programmer; but for others \nit's probably not so obvious as \"yield\" has a number of meanings in \nnormal English similar to \"give up\", \"give over\" etc\n\nrest - not quite as good as \"wait\"; machines wait for humans, but the \nnever need to rest\n\ntimeout - sounds like an error condition, so not really appropriate\n\nSorry for participating in the painting. Just thought that \"wait\" was \ngood enough to merit some positive feedback.\n\nCheers,\nWincent\n"},{"id":"100647","messageId":"alpine.DEB.1.00.0901152027130.3586@pacific.mpi-cbg.de","threadId":"17183","inReplyTo":"87ocy8flka.fsf@cup.kalibalik.dk","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-15T19:28:00Z","receivedAt":"2009-01-15T19:28:00Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Anders Melchiorsen wrote:\n\n> break\n\nAs rebase -i is just a loop of cherry-picks, as a C programmer I would \nthink: \"does this break out of the loop\"?\n\nCiao,\nDscho\n"},{"id":"100652","messageId":"76718490901151226l704d119bh297db4e91a4da05b@mail.gmail.com","threadId":"17183","inReplyTo":"8035E52E-D202-4C42-BDFD-DC7A925580A3@wincent.com","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-01-15T20:26:37Z","receivedAt":"2009-01-15T20:26:37Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Thu, Jan 15, 2009 at 2:27 PM, Wincent Colaiuta wrote:\n> wait - best suggestion so far, seeing as we can't use \"stop\"\n\nThis is a fun game. I like the color \"halt\".\n\nj.\n"},{"id":"100660","messageId":"D115E37C-D1BE-441B-BD7F-66C46D43CE1A@wincent.com","threadId":"17183","inReplyTo":"76718490901151226l704d119bh297db4e91a4da05b@mail.gmail.com","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-01-15T21:58:09Z","receivedAt":"2009-01-15T21:58:09Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 15/1/2009, a las 21:26, Jay Soffian escribió:\n\n> On Thu, Jan 15, 2009 at 2:27 PM, Wincent Colaiuta \n> wrote:\n>> wait - best suggestion so far, seeing as we can't use \"stop\"\n>\n> This is a fun game. I like the color \"halt\".\n\nOoh, yes. An even better color.\n\nWincent\n"},{"id":"100661","messageId":"7vvdsgql17.fsf@gitster.siamese.dyndns.org","threadId":"17183","inReplyTo":"20090115153529.GA13961@neumann","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-15T22:09:08Z","receivedAt":"2009-01-15T22:09:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor writes:\n\n> I think we might want do differentiate editing a commit (modifying\n> either the commit message or the patch or both) or splitting a commit.\n>\n> The first is served well with the current 'edit' rebase command IMHO.\n> I don't really see the point of the additional 'git reset --soft\n> HEAD^'.\n>\n> * If you want to edit the commit message only, then you are\n> better off with 'git commit --amend', because it preserves the\n> previous commit message. But with 'git reset --soft HEAD^' and\n> 'git commit' the commit message is \"lost\"; you have to use 'git\n> commit -c ORIG_HEAD' instead, which is not that straightforward\n> (and we don't have completion support for it).\n\nI agree that is a true disadvantage that shows \"reset --soft HEAD^\" is a\nbad idea (you could still say commit -c @{1}, though).\n\n> For the second we could introduce a new rebase command like 'split',\n> which would do the same as 'edit' but would also perform that 'git\n> reset HEAD^' mentioned in the documentation automatically.\n\nPerhaps. \n"},{"id":"100664","messageId":"bd6139dc0901151420j4ae62433uc0cc70d86dc45cfa@mail.gmail.com","threadId":"17183","inReplyTo":"7vvdsgql17.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-15T22:20:08Z","receivedAt":"2009-01-15T22:20:08Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Jan 15, 2009 at 23:09, Junio C Hamano wrote:\n> I agree that is a true disadvantage that shows \"reset --soft HEAD^\" is a\n> bad idea (you could still say commit -c @{1}, though).\n\nBut it's not:\n\"It also makes sure that a pre-filled editor is fired up when doing\n\"git rebase --continue\", in case the user just wanted to fix the\ncommit message.\"\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"100669","messageId":"20090115225912.GL9794@neumann","threadId":"17183","inReplyTo":"bd6139dc0901151420j4ae62433uc0cc70d86dc45cfa@mail.gmail.com","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2009-01-15T22:59:12Z","receivedAt":"2009-01-15T22:59:12Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Jan 15, 2009 at 11:20:08PM +0100, Sverre Rabbelier wrote:\n> On Thu, Jan 15, 2009 at 23:09, Junio C Hamano wrote:\n> > I agree that is a true disadvantage that shows \"reset --soft HEAD^\" is a\n> > bad idea (you could still say commit -c @{1}, though).\n> \n> But it's not:\n> \"It also makes sure that a pre-filled editor is fired up when doing\n> \"git rebase --continue\", in case the user just wanted to fix the\n> commit message.\"\n\nIndeed, but in this case the rebase process will continue after\nfinishing the commit message. OTOH, with the current behaviour, you\nmust do a 'git commit --amend && git rebase --continue', which might\nseem more complicated at first sight, but...\n\nBut the current behaviour of the 'edit' rebase command gives you the\npossibility of adding further commits on top of the selected one\n(after you have edited that or left intact, doesn't matter). To do\nthat with this automatic 'reset --soft HEAD^' modification you would\nfirst need to 'git commit -c @{1}' to keep the selected commit before\ngoing on with adding further commits, which is not quite nice.\n\n\nRegards,\nGábor\n"},{"id":"100675","messageId":"20090116001139.GA26357@atjola.homenet","threadId":"17183","inReplyTo":"20090115225912.GL9794@neumann","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-01-16T00:11:39Z","receivedAt":"2009-01-16T00:11:39Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.01.15 23:59:12 +0100, SZEDER Gábor wrote:\n> On Thu, Jan 15, 2009 at 11:20:08PM +0100, Sverre Rabbelier wrote:\n> > On Thu, Jan 15, 2009 at 23:09, Junio C Hamano wrote:\n> > > I agree that is a true disadvantage that shows \"reset --soft HEAD^\" is a\n> > > bad idea (you could still say commit -c @{1}, though).\n> > \n> > But it's not:\n> > \"It also makes sure that a pre-filled editor is fired up when doing\n> > \"git rebase --continue\", in case the user just wanted to fix the\n> > commit message.\"\n> \n> Indeed, but in this case the rebase process will continue after\n> finishing the commit message. OTOH, with the current behaviour, you\n> must do a 'git commit --amend && git rebase --continue', which might\n> seem more complicated at first sight, but...\n\nNo, you don't have to do that. As long as you only want to \"edit\" the\ncommit you marked as \"edit\", you only need to use \"git add\" and \"git\nrebase --continue\". rebase -i checks whether HEAD still resolves to the\nsame commit and if so, it automatically does the soft reset for you.\n\nMaybe we should just advertise that in the message provided by rebase\nafter it stops? I'm afraid I can't come up with a sane wording though,\nas there are still cases when you need to commit yourself, eg. when you\nuse reset. And getting that into one simple sentence seems a bit hard\n(for me).\n\nA bit off-topic: The \"auto-amend\" code path passes --no-verify to git\ncommit. What's the reason for doing that? I actually always expected\nthat to use my pre-commit hook to stop me from committing crap. :-/\n\nBjörn\n"},{"id":"100676","messageId":"7v3afkqcnt.fsf@gitster.siamese.dyndns.org","threadId":"17183","inReplyTo":"20090115225912.GL9794@neumann","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-16T01:09:58Z","receivedAt":"2009-01-16T01:09:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor writes:\n\n> But the current behaviour of the 'edit' rebase command gives you the\n> possibility of adding further commits on top of the selected one\n> (after you have edited that or left intact, doesn't matter). To do\n> that with this automatic 'reset --soft HEAD^' modification you would\n> first need to 'git commit -c @{1}' to keep the selected commit before\n> going on with adding further commits, which is not quite nice.\n\nYeah, I agree.\n\nI think my confusion mostly came from perception, and the way the \"edit\"\naction is (not) explained.\n\nWhat \"edit\" means is \"pick this commit and then stop to give control back\nto the user. The user is free to muck with the history starting from the\nstate after picking the named commit in any way, and --continue will carry\non the rest of the insns from the state\" [*1*]. Once I realize that,\nit becomes clear what it means to do any of the following when \"edit\"\ngives the control back to me:\n\n (1) commit --amend (with or without changing the tree and message); this\n is the originally intended usage. Edit the commit the machinery just\n picked and let it continue. The end result is as if you edited one\n commit in the sequence.\n\n (2) making completely unrelated commits on top of the state \"edit\" gave\n you; this inserts a new commit in the sequence.\n\n (3) first \"reset HEAD^\", commit selected parts of the difference in one\n commit, commit the reaminder in another commit; this splits the\n commit the machinery just picked into two.\n\nBy the way, \"rebase --continue\" codepath has extra code that does\nsomething magical when the index does not match the HEAD commit. I\nsuspect what it does makes sense only in the originally intended usage\nsequence (i.e. \"edit\" stops, you want to do \"commit --amend\" and then\n\"rebase --continue\" but somehow you forgot to commit everything).\n\nHow well does that logic work when the user wanted to do (2) or (3) above,\nand happened to have the index unclean when s/he said \"rebase --continue\"?\nDoes it do something nonsensical?\n\n[Footnote]\n\n*1* Explained the same way, \"pick\" is \"cherry-pick the named commit to\nreplay its effect and then continue\".\n"},{"id":"100677","messageId":"alpine.DEB.1.00.0901160234160.3586@pacific.mpi-cbg.de","threadId":"17183","inReplyTo":"20090116001139.GA26357@atjola.homenet","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-16T01:34:57Z","receivedAt":"2009-01-16T01:34:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 16 Jan 2009, Björn Steinbrink wrote:\n\n> A bit off-topic: The \"auto-amend\" code path passes --no-verify to git \n> commit. What's the reason for doing that? I actually always expected \n> that to use my pre-commit hook to stop me from committing crap. :-/\n\nIIRC people requested that rebase commits their crap without complaining \n:-)\n\nCiao,\nDscho\n"},{"id":"100711","messageId":"200901161050.13971.johan@herland.net","threadId":"17183","inReplyTo":"76718490901151226l704d119bh297db4e91a4da05b@mail.gmail.com","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-01-16T09:50:13Z","receivedAt":"2009-01-16T09:50:13Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Thursday 15 January 2009, Jay Soffian wrote:\n> On Thu, Jan 15, 2009 at 2:27 PM, Wincent Colaiuta wrote:\n> > wait - best suggestion so far, seeing as we can't use \"stop\"\n> This is a fun game. I like the color \"halt\".\n\nNice. I like this one as well.\n\nAfter some more thinking (triggered by Junio's recent post in another \nsubthread), it occured to me that the current behaviour (currently known \nas \"edit\") is not something that is applied to one of the commits in the \nrebase list per se, but rather something that affects the rebase machinery \n*between* commits. So instead of\n\n\tedit e8902c1 Foo\n\nwe should consider something like\n\n\tpick e8902c1 Foo\n\thalt\n\nwhich I think better encapsulates the current behaviour. (IOW, insert \"halt\" \nwherever you'd like to muck about with the history; e.g. \ndoing \"commit --amend\", inserting extra commits, etc.)\n\nWe can then make shortcuts for common actions:\n\n\tamend e8902c1 Foo\n\ndoes a \"pick\" followed by \"commit --amend\" (for editing the commit message), \nfollowed by \"rebase --continue\". Finally, we implement Anders' suggestion:\n\n\tmodify e8902c1 Foo\n\n(or whatever synonym for \"edit\" we converge on) does a \"pick\" followed by \na \"reset --soft HEAD^\", followed by a \"halt\".\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"100713","messageId":"49548.bFoQE3daRhY=.1232101666.squirrel@webmail.hotelhot.dk","threadId":"17183","inReplyTo":"200901161050.13971.johan@herland.net","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Anders Melchiorsen","fromEmail":"mail@cup.kalibalik.dk","sentAt":"2009-01-16T10:27:46Z","receivedAt":"2009-01-16T10:27:46Z","isPatch":true,"sender":{"key":"mail@cup.kalibalik.dk","avatar":null},"body":"Johan Herland wrote:\n\n> \tedit e8902c1 Foo\n>\n> we should consider something like\n>\n> \tpick e8902c1 Foo\n> \thalt\n\nOf all the suggestions, I like this one the most. Also, when placed like\nthis, I am suddenly no longer opposed to the word \"halt\".\n\n\n> \tamend e8902c1 Foo\n>\n> does a \"pick\" followed by \"commit --amend\" (for editing the commit\n> message), followed by \"rebase --continue\".\n\nI do not think that \"amend\" is the best word for editing only the commit\nmessage. A \"commit --amend\" can also make a new tree, so reusing the word\nwith a different meaning could be bad.\n\nAs for alternatives, however, I can only come up with \"copyedit\", and that\nis so horrible that I will not even propose it :-)\n\n\nCheers,\nAnders.\n"},{"id":"100714","messageId":"200901161158.06828.johan@herland.net","threadId":"17183","inReplyTo":"49548.bFoQE3daRhY=.1232101666.squirrel@webmail.hotelhot.dk","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-01-16T10:58:06Z","receivedAt":"2009-01-16T10:58:06Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Friday 16 January 2009, Anders Melchiorsen wrote:\n> Johan Herland wrote:\n> > \tamend e8902c1 Foo\n> >\n> > does a \"pick\" followed by \"commit --amend\" (for editing the commit\n> > message), followed by \"rebase --continue\".\n>\n> I do not think that \"amend\" is the best word for editing only the\n> commit message. A \"commit --amend\" can also make a new tree, so\n> reusing the word with a different meaning could be bad.\n>\n> As for alternatives, however, I can only come up with \"copyedit\", and\n> that is so horrible that I will not even propose it :-)\n\n\"rephrase\"?\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"100723","messageId":"alpine.DEB.1.00.0901161305520.3586@pacific.mpi-cbg.de","threadId":"17183","inReplyTo":"7v3afkqcnt.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-16T12:10:58Z","receivedAt":"2009-01-16T12:10:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Jan 2009, Junio C Hamano wrote:\n\n> (2) making completely unrelated commits on top of the state \"edit\" gave\n> you; this inserts a new commit in the sequence.\n> \n> (3) first \"reset HEAD^\", commit selected parts of the difference in one\n> commit, commit the reaminder in another commit; this splits the\n> commit the machinery just picked into two.\n> \n> By the way, \"rebase --continue\" codepath has extra code that does\n> something magical when the index does not match the HEAD commit. I\n> suspect what it does makes sense only in the originally intended usage\n> sequence (i.e. \"edit\" stops, you want to do \"commit --amend\" and then\n> \"rebase --continue\" but somehow you forgot to commit everything).\n> \n> How well does that logic work when the user wanted to do (2) or (3) above,\n> and happened to have the index unclean when s/he said \"rebase --continue\"?\n> Does it do something nonsensical?\n\nAFAICT the special handling is the only sane way to cope with (2) and (3), \nif it is the special handling that I am talking about:\n\nIf the current HEAD differs with the HEAD just after dropping to the \nshell, rebase --continue will _not_ just commit with the recorded \ninformation and continue.\n\nThe intended effect is that when you split a commit and continue with \nuncommitted changes, it will not just go ahead and call an editor with the \noriginal commit message: this message is now likely wrong.\n\nIt will only call an editor with the original message as a convenience \nwhen you did changes, but did not commit at all before continuing. Just a \nconvenience I found quite useful.\n\nCiao,\nDscho\n"},{"id":"100726","messageId":"20090116124239.GA28870@neumann","threadId":"17183","inReplyTo":"200901161158.06828.johan@herland.net","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2009-01-16T12:42:39Z","receivedAt":"2009-01-16T12:42:39Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Jan 16, 2009 at 11:58:06AM +0100, Johan Herland wrote:\n> On Friday 16 January 2009, Anders Melchiorsen wrote:\n> > Johan Herland wrote:\n> > > \tamend e8902c1 Foo\n> > >\n> > > does a \"pick\" followed by \"commit --amend\" (for editing the commit\n> > > message), followed by \"rebase --continue\".\n> >\n> > I do not think that \"amend\" is the best word for editing only the\n> > commit message. A \"commit --amend\" can also make a new tree, so\n> > reusing the word with a different meaning could be bad.\n> >\n> > As for alternatives, however, I can only come up with \"copyedit\", and\n> > that is so horrible that I will not even propose it :-)\n> \n> \"rephrase\"?\n\nThis is the first one that I found acceptable.\n\n'amend', 'modify' and 'edit' are just too close and non-intuitive:\nthey don't indicate _what_ will be amended, modified or edited at all.\n\n'rephrase', on the other hand, is better, as you can rephrase a commit\nmessage, but it's weird to say \"rephrase the patch\". But it's still\nnot as to-the-point as 'editmsg' (but that one has conflicting\nabbreviation).\n\nBest,\nGábor\n"},{"id":"100728","messageId":"alpine.DEB.1.00.0901161357230.3586@pacific.mpi-cbg.de","threadId":"17183","inReplyTo":"20090116124239.GA28870@neumann","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-16T12:57:57Z","receivedAt":"2009-01-16T12:57:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 16 Jan 2009, SZEDER Gábor wrote:\n\n> On Fri, Jan 16, 2009 at 11:58:06AM +0100, Johan Herland wrote:\n> \n> > \"rephrase\"?\n> \n> This is the first one that I found acceptable.\n\nI assume you missed \nhttp://article.gmane.org/gmane.comp.version-control.git/105783 in all that \nbikeshedding?\n\nCiao,\nDscho"},{"id":"100730","messageId":"bd6139dc0901160512x284bcd00x5d4c088e1771d86e@mail.gmail.com","threadId":"17183","inReplyTo":"200901161050.13971.johan@herland.net","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-01-16T13:12:07Z","receivedAt":"2009-01-16T13:12:07Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Fri, Jan 16, 2009 at 10:50, Johan Herland wrote:\n> we should consider something like\n> pick e8902c1 Foo\n> halt\n\nI very much like this suggestion, Stephan, is this somewhat similar to\nhow git sequencer will do things?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"100736","messageId":"20090116132714.GN9794@neumann","threadId":"17183","inReplyTo":"alpine.DEB.1.00.0901161357230.3586@pacific.mpi-cbg.de","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2009-01-16T13:27:14Z","receivedAt":"2009-01-16T13:27:14Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Jan 16, 2009 at 01:57:57PM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Fri, 16 Jan 2009, SZEDER Gábor wrote:\n> \n> > On Fri, Jan 16, 2009 at 11:58:06AM +0100, Johan Herland wrote:\n> > \n> > > \"rephrase\"?\n> > \n> > This is the first one that I found acceptable.\n> \n> I assume you missed \n> http://article.gmane.org/gmane.comp.version-control.git/105783 in all that \n> bikeshedding?\n\nYes, I indeed missed that. And still think that 'rephrase' is best\namong all the suggestions for this \"edit just the commit message\"\nthing. ('editmsg' conflicts; 'amend', 'modify', and 'correct' are\nnot obvious enough (they don't clearly indicate what will be\nmodified); and I'm not sure about 'redact', but I don't really like it\nbecause I had to look it up in the dictionary first).\n\nBest,\nGábor\n"},{"id":"100741","messageId":"22A54F3C-DC15-4589-B796-D0E7032EC515@wincent.com","threadId":"17183","inReplyTo":"20090116132714.GN9794@neumann","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-01-16T14:28:25Z","receivedAt":"2009-01-16T14:28:25Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 16/1/2009, a las 14:27, SZEDER Gábor escribió:\n\n> On Fri, Jan 16, 2009 at 01:57:57PM +0100, Johannes Schindelin wrote:\n>> Hi,\n>>\n>> On Fri, 16 Jan 2009, SZEDER Gábor wrote:\n>>\n>>> On Fri, Jan 16, 2009 at 11:58:06AM +0100, Johan Herland wrote:\n>>>\n>>>> \"rephrase\"?\n>>>\n>>> This is the first one that I found acceptable.\n>>\n>> I assume you missed\n>> http://article.gmane.org/gmane.comp.version-control.git/105783 in \n>> all that\n>> bikeshedding?\n>\n> Yes, I indeed missed that. And still think that 'rephrase' is best\n> among all the suggestions for this \"edit just the commit message\"\n> thing. ('editmsg' conflicts; 'amend', 'modify', and 'correct' are\n> not obvious enough (they don't clearly indicate what will be\n> modified); and I'm not sure about 'redact', but I don't really like it\n> because I had to look it up in the dictionary first).\n\nTwo more colors for consideration:\n\n - \"msg\"/\"msgedit\"/\"message\" or similar\n - \"reword\"\n\nI agree with Gábor that options like \"modify\" aren't clear because \nthere's nothing in them that suggests that they're intended to operate \non the commit _message_.\n\nWincent\n"},{"id":"100760","messageId":"20090116172640.GE28177@leksak.fem-net","threadId":"17183","inReplyTo":"bd6139dc0901160512x284bcd00x5d4c088e1771d86e@mail.gmail.com","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2009-01-16T17:26:40Z","receivedAt":"2009-01-16T17:26:40Z","isPatch":true,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nSverre Rabbelier wrote:\n> On Fri, Jan 16, 2009 at 10:50, Johan Herland wrote:\n> > we should consider something like\n> > pick e8902c1 Foo\n> > halt\n> \n> I very much like this suggestion, Stephan, is this somewhat similar to\n> how git sequencer will do things?\n\nYes, it is\n\n\tpick e8902c1 # Foo\n\tpause\n\nin sequencer currently. Of course, \"pause\" could be renamed to \"halt\",\n\"stop\" or whatever you like. But I think everyone likes something\ndifferent.\n\nAnd\n\n\tedit e8902c1 # Foo\n\nis simply a shortcut for the pick-pause above.\n(Or \"e e8902c1\" instead of edit, which works, too.)\n\nI usually prefer typing \"cw edit\" over \"o pause\" into vim\nin such cases.\n\nRegards,\n Stephan\n\n-- \nStephan Beyer , PGP 0x6EDDD207FCC5040F\n"},{"id":"100774","messageId":"alpine.DEB.1.00.0901162206150.3586@pacific.mpi-cbg.de","threadId":"17183","inReplyTo":"20090116172640.GE28177@leksak.fem-net","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-16T21:06:59Z","receivedAt":"2009-01-16T21:06:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 16 Jan 2009, Stephan Beyer wrote:\n\n> Of course, \"pause\" could be renamed to \"halt\", \"stop\" or whatever you \n> like. But I think everyone likes something different.\n\nBoth 's' and 'p' shortcuts are already taken, unfortunately.\n\nCiao,\nDscho\n"},{"id":"100902","messageId":"877i4tmmnx.fsf@cup.kalibalik.dk","threadId":"17183","inReplyTo":"20090116001139.GA26357@atjola.homenet","subject":"Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state","fromName":"Anders Melchiorsen","fromEmail":"mail@cup.kalibalik.dk","sentAt":"2009-01-18T01:24:18Z","receivedAt":"2009-01-18T01:24:18Z","isPatch":true,"sender":{"key":"mail@cup.kalibalik.dk","avatar":null},"body":"Björn Steinbrink writes:\n\n> No, you don't have to do that. As long as you only want to \"edit\"\n> the commit you marked as \"edit\", you only need to use \"git add\" and\n> \"git rebase --continue\". rebase -i checks whether HEAD still\n> resolves to the same commit and if so, it automatically does the\n> soft reset for you.\n>\n> Maybe we should just advertise that in the message provided by\n> rebase after it stops? I'm afraid I can't come up with a sane\n> wording though, as there are still cases when you need to commit\n> yourself, eg. when you use reset. And getting that into one simple\n> sentence seems a bit hard (for me).\n\nI was happy to learn that trick when looking at the source, so I agree\nthat it is a good idea to advertise it. You are right that it is hard\nto describe well in few words, though. Does somebody feel like\nrepainting this?\n\n\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -336,14 +336,13 @@ do_next () {\n \t\tmake_patch $sha1\n \t\tgit rev-parse --verify HEAD > \"$DOTEST\"/amend\n \t\twarn \"Stopped at $sha1... $rest\"\n-\t\twarn \"You can amend the commit now, with\"\n-\t\twarn\n-\t\twarn \"\tgit commit --amend\"\n-\t\twarn\n-\t\twarn \"Once you are satisfied with your changes, run\"\n+\t\twarn \"You can amend the commit now, by marking\"\n+\t\twarn \"paths with 'git add ' and running\"\n \t\twarn\n \t\twarn \"\tgit rebase --continue\"\n \t\twarn\n+\t\twarn \"If you want to create new commits, run\"\n+\t\twarn \"'git commit' yourself before continuing.\"\n \t\texit 0\n \t\t;;\n \tsquash|s)\n"}]}