{"thread":{"id":"21374","subject":"possible usability issue in rebase -i?","startedAt":"2009-10-27T10:13:42Z","lastAt":"2009-10-28T14:41:41Z","messageCount":12,"participants":["Erik Faye-Lund","Jan Krüger","Johannes Schindelin","Thomas Rast","Baz","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"126001","messageId":"40aa078e0910270313j5dc68576v86a3947f0dc7f9f@mail.gmail.com","threadId":"21374","inReplyTo":null,"subject":"possible usability issue in rebase -i?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2009-10-27T10:13:42Z","receivedAt":"2009-10-27T10:13:42Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"I recently came over a not-overly-helpful error in git rebase -i, when\na line got wrapped by the editor so that a part of the commit-message\nwas interpreted as a command:\n\n---\n$ git rebase -i HEAD~20\n\nUnknown command: .\nfatal: ambiguous argument 'Please fix this in the file C:/msysgit/git/.git/rebas\ne-merge/git-rebase-todo.': unknown revision or path not in the working tree.\nUse '--' to separate paths from revisions\nfatal: Not a valid object name Please fix this in the file C:/msysgit/git/.git/r\nebase-merge/git-rebase-todo.\nfatal: bad revision 'Please fix this in the file C:/msysgit/git/.git/rebase-merg\ne/git-rebase-todo.'\n\n$ git --version\ngit version 1.6.5.1386.g43a7a.dirty\n---\n\nIn this particular case, the first character on the new line was '.',\nso the first line of the error message makes perfect sense, but the\nlines that followed the real error got me pretty confused. Perhaps\nthis is something that could be cleaned away? I'd think that an\nunknown command always should be fatal, and not need to propagate\nfurther. But I might be wrong, as I'm not familiar with the inner\nworkings of rebase -i.\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"126008","messageId":"20091027133932.60b996c3@perceptron","threadId":"21374","inReplyTo":"40aa078e0910270313j5dc68576v86a3947f0dc7f9f@mail.gmail.com","subject":"[PATCH] rebase -i: more graceful handling of invalid commands","fromName":"Jan Krüger","fromEmail":"jk@jk.gs","sentAt":"2009-10-27T12:39:32Z","receivedAt":"2009-10-27T12:39:32Z","isPatch":true,"sender":{"key":"jk@jk.gs","avatar":"https://avatars.githubusercontent.com/u/1774?v=4"},"body":"Currently, when there is an invalid command, the rest of the line is\nstill treated as if the command had been valid, i.e. rebase -i attempts\nto produce a patch, using the next argument as a SHA1 name. If there is\nno next argument or an invalid one, very confusing error messages\nappear (the line was '.'; path to git-rebase-todo substituted):\n\nUnknown command: .\nfatal: ambiguous argument 'Please fix this in the file $somefile.':\nunknown revision or path not in the working tree.\nUse '--' to separate paths from revisions\nfatal: Not a valid object name Please fix this in the file $somefile.\nfatal: bad revision 'Please fix this in the file $somefile.'\n\nInstead, verify the validity of the remaining line and error out earlier\nif necessary.\n\nSigned-off-by: Jan Krüger \n---\n\n> I recently came over a not-overly-helpful error in git rebase -i, when\n> a line got wrapped by the editor so that a part of the commit-message\n> was interpreted as a command:\n\nHere is a suggested fix.\n\n git-rebase--interactive.sh | 7 ++++++-\n 1 files changed, 6 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex a1879e3..fdd8eb6 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -416,7 +416,12 @@ do_next () {\n \t\t;;\n \t*)\n \t\twarn \"Unknown command: $command $sha1 $rest\"\n-\t\tdie_with_patch $sha1 \"Please fix this in the file $TODO.\"\n+\t\tif git rev-parse --verify -q \"$sha\" >/dev/null\n+\t\tthen\n+\t\t\tdie_with_patch $sha1 \"Please fix this in the file $TODO.\"\n+\t\telse\n+\t\t\tdie \"Please fix this in the file $TODO.\"\n+\t\tfi\n \t\t;;\n \tesac\n \ttest -s \"$TODO\" && return\n-- \n1.6.5.rc1\n"},{"id":"126020","messageId":"alpine.DEB.1.00.0910271517180.11562@felix-maschine","threadId":"21374","inReplyTo":"20091027133932.60b996c3@perceptron","subject":"Re: [PATCH] rebase -i: more graceful handling of invalid commands","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-27T14:17:28Z","receivedAt":"2009-10-27T14:17:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Oct 2009, Jan Krüger wrote:\n\n> Currently, when there is an invalid command, the rest of the line is\n> still treated as if the command had been valid, i.e. rebase -i attempts\n> to produce a patch, using the next argument as a SHA1 name. If there is\n> no next argument or an invalid one, very confusing error messages\n> appear (the line was '.'; path to git-rebase-todo substituted):\n> \n> Unknown command: .\n> fatal: ambiguous argument 'Please fix this in the file $somefile.':\n> unknown revision or path not in the working tree.\n> Use '--' to separate paths from revisions\n> fatal: Not a valid object name Please fix this in the file $somefile.\n> fatal: bad revision 'Please fix this in the file $somefile.'\n> \n> Instead, verify the validity of the remaining line and error out earlier\n> if necessary.\n> \n> Signed-off-by: Jan Krüger \n\nACK,\nDscho"},{"id":"126021","messageId":"200910271521.09164.trast@student.ethz.ch","threadId":"21374","inReplyTo":"20091027133932.60b996c3@perceptron","subject":"Re: [PATCH] rebase -i: more graceful handling of invalid commands","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-27T14:21:08Z","receivedAt":"2009-10-27T14:21:08Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jan Krüger wrote:\n> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> index a1879e3..fdd8eb6 100755\n> --- a/git-rebase--interactive.sh\n> +++ b/git-rebase--interactive.sh\n> @@ -416,7 +416,12 @@ do_next () {\n> \t\t;;\n> \t*)\n> \t\twarn \"Unknown command: $command $sha1 $rest\"\n> -\t\tdie_with_patch $sha1 \"Please fix this in the file $TODO.\"\n> +\t\tif git rev-parse --verify -q \"$sha\" >/dev/null\n\nI think you need s/sha/sha1/ here?\n\n> +\t\tthen\n> +\t\t\tdie_with_patch $sha1 \"Please fix this in the file $TODO.\"\n> +\t\telse\n> +\t\t\tdie \"Please fix this in the file $TODO.\"\n> +\t\tfi\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"126023","messageId":"20091027155814.0de65db5@perceptron","threadId":"21374","inReplyTo":"200910271521.09164.trast@student.ethz.ch","subject":"[PATCH v2] rebase -i: more graceful handling of invalid commands","fromName":"Jan Krüger","fromEmail":"jk@jk.gs","sentAt":"2009-10-27T14:58:14Z","receivedAt":"2009-10-27T14:58:14Z","isPatch":true,"sender":{"key":"jk@jk.gs","avatar":"https://avatars.githubusercontent.com/u/1774?v=4"},"body":"Currently, when there is an invalid command, the rest of the line is\nstill treated as if the command had been valid, i.e. rebase -i attempts\nto produce a patch, using the next argument as a SHA1 name. If there is\nno next argument or an invalid one, very confusing error messages\nappear (the line was '.'; path to git-rebase-todo substituted):\n\nUnknown command: .\nfatal: ambiguous argument 'Please fix this in the file $somefile.':\nunknown revision or path not in the working tree.\nUse '--' to separate paths from revisions\nfatal: Not a valid object name Please fix this in the file $somefile.\nfatal: bad revision 'Please fix this in the file $somefile.'\n\nInstead, verify the validity of the remaining line and error out earlier\nif necessary.\n\nSigned-off-by: Jan Krüger \nAcked-by: Johannes Schindelin \n---\n\nThomas Rast wrote:\n> I think you need s/sha/sha1/ here?\n\nOf course. For some reason I forgot testing the code path where the\nSHA1 is actually valid. Sorry about that.\n\nDscho's ACK lifted off\n.\n\n git-rebase--interactive.sh | 7 ++++++-\n 1 files changed, 6 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex a1879e3..fdd8eb6 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -416,7 +416,12 @@ do_next () {\n \t\t;;\n \t*)\n \t\twarn \"Unknown command: $command $sha1 $rest\"\n-\t\tdie_with_patch $sha1 \"Please fix this in the file $TODO.\"\n+\t\tif git rev-parse --verify -q \"$sha1\" >/dev/null\n+\t\tthen\n+\t\t\tdie_with_patch $sha1 \"Please fix this in the file $TODO.\"\n+\t\telse\n+\t\t\tdie \"Please fix this in the file $TODO.\"\n+\t\tfi\n \t\t;;\n \tesac\n \ttest -s \"$TODO\" && return\n-- \n1.6.5.rc1\n"},{"id":"126027","messageId":"2faad3050910270817l71394722nda55265ed96722df@mail.gmail.com","threadId":"21374","inReplyTo":"40aa078e0910270313j5dc68576v86a3947f0dc7f9f@mail.gmail.com","subject":"Re: possible usability issue in rebase -i?","fromName":"Baz","fromEmail":"brian.ewins@gmail.com","sentAt":"2009-10-27T15:17:08Z","receivedAt":"2009-10-27T15:17:08Z","isPatch":false,"sender":{"key":"brian.ewins@gmail.com","avatar":"https://gravatar.com/avatar/9ac03d89105e50a7151e695a1b4b1228151064ec3ac380a73b74ab397796baf7?d=mp&s=160"},"body":"2009/10/27 Erik Faye-Lund :\n> I recently came over a not-overly-helpful error in git rebase -i, when\n> a line got wrapped by the editor so that a part of the commit-message\n> was interpreted as a command:\n>\n> ---\n> $ git rebase -i HEAD~20\n> \n> Unknown command: .\n> fatal: ambiguous argument 'Please fix this in the file C:/msysgit/git/.git/rebas\n> e-merge/git-rebase-todo.': unknown revision or path not in the working tree.\n> Use '--' to separate paths from revisions\n> fatal: Not a valid object name Please fix this in the file C:/msysgit/git/.git/r\n> ebase-merge/git-rebase-todo.\n> fatal: bad revision 'Please fix this in the file C:/msysgit/git/.git/rebase-merg\n> e/git-rebase-todo.'\n>\n> $ git --version\n> git version 1.6.5.1386.g43a7a.dirty\n> ---\n>\n> In this particular case, the first character on the new line was '.',\n> so the first line of the error message makes perfect sense, but the\n> lines that followed the real error got me pretty confused. Perhaps\n> this is something that could be cleaned away? I'd think that an\n> unknown command always should be fatal, and not need to propagate\n> further. But I might be wrong, as I'm not familiar with the inner\n> workings of rebase -i.\n\nI've got a somewhat related minor usability issue with rebase -i. I\naccidentally typed something like 'git rebase -i -z' and got this\nmessage:\n\nerror: unknown switch `z'\nusage: git-rebase [-i] [options] [--] []\n or: git-rebase [-i] (--continue | --abort | --skip)\n\nAvailable options are\n -v, --verbose display a diffstat of what changed upstream\n --onto ... rebase onto given branch instead of upstream\n -p, --preserve-merges\n try to recreate merges instead of ignoring them\n -s, --strategy ... use the given merge strategy\n -m, --merge always used (no-op)\n -i, --interactive always used (no-op)\n\nThe last two lines were the surprise. It suggested to me that '-i' and\n'-m' were now the defaults for git-rebase - which of course they're\nnot. A user would not know that this is actually reporting the flags\nthat work for git-rebase--interactive, especially since that's not\nwhat the command calls itself. I wasn't sure about the best approach\nto fixing this - the only comparable commands that pass arbitrary\nflags down to an exec'd program make it clear what program is going to\nbe called (usually git merge) and so interpreting errors is easier.\n\nIt seems the intent here was to signal that the flags are different\nonce a rebase is in progress, but this usage message is shown when\nrebase -i -z is called in any state.\n\nCheers,\nBrian\n>\n> --\n> Erik \"kusma\" Faye-Lund\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"126030","messageId":"40aa078e0910270850u6ffec41cj372da11d9df533f@mail.gmail.com","threadId":"21374","inReplyTo":"2faad3050910270817l71394722nda55265ed96722df@mail.gmail.com","subject":"Re: possible usability issue in rebase -i?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2009-10-27T15:50:44Z","receivedAt":"2009-10-27T15:50:44Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Tue, Oct 27, 2009 at 4:17 PM, Baz wrote:\n> I've got a somewhat related minor usability issue with rebase -i. I\n> accidentally typed something like 'git rebase -i -z' and got this\n> message:\n>\n> error: unknown switch `z'\n> usage: git-rebase [-i] [options] [--] []\n>   or: git-rebase [-i] (--continue | --abort | --skip)\n>\n> Available options are\n>    -v, --verbose         display a diffstat of what changed upstream\n>    --onto ...            rebase onto given branch instead of upstream\n>    -p, --preserve-merges\n>                          try to recreate merges instead of ignoring them\n>    -s, --strategy ...    use the given merge strategy\n>    -m, --merge           always used (no-op)\n>    -i, --interactive     always used (no-op)\n>\n> The last two lines were the surprise. It suggested to me that '-i' and\n> '-m' were now the defaults for git-rebase - which of course they're\n> not. A user would not know that this is actually reporting the flags\n> that work for git-rebase--interactive, especially since that's not\n> what the command calls itself. I wasn't sure about the best approach\n> to fixing this - the only comparable commands that pass arbitrary\n> flags down to an exec'd program make it clear what program is going to\n> be called (usually git merge) and so interpreting errors is easier.\n>\n> It seems the intent here was to signal that the flags are different\n> once a rebase is in progress, but this usage message is shown when\n> rebase -i -z is called in any state.\n\nIf that is the case, my instinct tells me that this information should\nbe reflected in the usage-string (instead of the parameter\ndescription). Something like this?\n\n--->8---\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 23ded48..3ed5f94 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -13,15 +13,15 @@\n OPTIONS_KEEPDASHDASH=\n OPTIONS_SPEC=\"\\\n git-rebase [-i] [options] [--] []\n-git-rebase [-i] (--continue | --abort | --skip)\n+git-rebase [-i] [-m] (--continue | --abort | --skip)\n --\n Available options are\n v,verbose display a diffstat of what changed upstream\n onto= rebase onto given branch instead of upstream\n p,preserve-merges try to recreate merges instead of ignoring them\n s,strategy= use the given merge strategy\n-m,merge always used (no-op)\n-i,interactive always used (no-op)\n+m,merge use merging strategies\n+i,interactive interactively edit commits\n Actions:\n continue continue rebasing process\n abort abort rebasing process and restore original branch\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"126058","messageId":"2faad3050910271405k4a391184vb978b9b35484383b@mail.gmail.com","threadId":"21374","inReplyTo":"40aa078e0910270850u6ffec41cj372da11d9df533f@mail.gmail.com","subject":"Re: possible usability issue in rebase -i?","fromName":"Baz","fromEmail":"brian.ewins@gmail.com","sentAt":"2009-10-27T21:05:53Z","receivedAt":"2009-10-27T21:05:53Z","isPatch":false,"sender":{"key":"brian.ewins@gmail.com","avatar":"https://gravatar.com/avatar/9ac03d89105e50a7151e695a1b4b1228151064ec3ac380a73b74ab397796baf7?d=mp&s=160"},"body":"2009/10/27 Erik Faye-Lund :\n> On Tue, Oct 27, 2009 at 4:17 PM, Baz wrote:\n>> I've got a somewhat related minor usability issue with rebase -i. I\n>> accidentally typed something like 'git rebase -i -z' and got this\n>> message:\n>>\n>> error: unknown switch `z'\n>> usage: git-rebase [-i] [options] [--] []\n>>   or: git-rebase [-i] (--continue | --abort | --skip)\n>>\n>> Available options are\n>>    -v, --verbose         display a diffstat of what changed upstream\n>>    --onto ...            rebase onto given branch instead of upstream\n>>    -p, --preserve-merges\n>>                          try to recreate merges instead of ignoring them\n>>    -s, --strategy ...    use the given merge strategy\n>>    -m, --merge           always used (no-op)\n>>    -i, --interactive     always used (no-op)\n>>\n>> The last two lines were the surprise. It suggested to me that '-i' and\n>> '-m' were now the defaults for git-rebase - which of course they're\n>> not. A user would not know that this is actually reporting the flags\n>> that work for git-rebase--interactive, especially since that's not\n>> what the command calls itself. I wasn't sure about the best approach\n>> to fixing this - the only comparable commands that pass arbitrary\n>> flags down to an exec'd program make it clear what program is going to\n>> be called (usually git merge) and so interpreting errors is easier.\n>>\n>> It seems the intent here was to signal that the flags are different\n>> once a rebase is in progress, but this usage message is shown when\n>> rebase -i -z is called in any state.\n>\n> If that is the case, my instinct tells me that this information should\n> be reflected in the usage-string (instead of the parameter\n> description). Something like this?\n\nI'm fine with this way of fixing it, but I'd make a few more changes...\n\n>\n> --->8---\n>\n> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> index 23ded48..3ed5f94 100755\n> --- a/git-rebase--interactive.sh\n> +++ b/git-rebase--interactive.sh\n> @@ -13,15 +13,15 @@\n>  OPTIONS_KEEPDASHDASH=\n>  OPTIONS_SPEC=\"\\\n>  git-rebase [-i] [options] [--] []\n\nUse the dashless form and be more consistent with the help - and\nmention '--root' here, it appears in the\nhelp below:\n\n-git-rebase [-i] [options] [--] []\n+git rebase [--interactive | -i] [options] [--onto ] [--]\n []\n+git rebase [--interactive | -i] [options] --onto --root\n[--] []\n\n\n> -git-rebase [-i] (--continue | --abort | --skip)\n> +git-rebase [-i] [-m] (--continue | --abort | --skip)\n\nAgain, dashless. And I'd not mention the useless -i here, the man page\ndoesn't either:\n\n-git-rebase [-i] (--continue | --abort | --skip)\n+git rebase (--continue | --abort | --skip)\n\n>  --\n>  Available options are\n>  v,verbose          display a diffstat of what changed upstream\n>  onto=              rebase onto given branch instead of upstream\n>  p,preserve-merges  try to recreate merges instead of ignoring them\n>  s,strategy=        use the given merge strategy\n> -m,merge            always used (no-op)\n> -i,interactive      always used (no-op)\n> +m,merge            use merging strategies\n> +i,interactive      interactively edit commits\n\nThese two items are misplaced in the help (I think). They're not like\nabort, continue, skip, but then, the man page doesn't group those\nseparately either.\n\n+no-verify override pre-rebase hook from stopping the operation\n+root rebase all reachable commmits up to the root(s)\n\n>  Actions:\n>  continue           continue rebasing process\n>  abort              abort rebasing process and restore original branch\n\nAs above, remove the next two lines after your patch:\n\n-no-verify override pre-rebase hook from stopping the operation\n-root rebase all reachable commmits up to the root(s)\n\n-Baz\n\n>\n> --\n> Erik \"kusma\" Faye-Lund\n>\n"},{"id":"126097","messageId":"7vmy3ct2a4.fsf@alter.siamese.dyndns.org","threadId":"21374","inReplyTo":"20091027155814.0de65db5@perceptron","subject":"Re: [PATCH v2] rebase -i: more graceful handling of invalid commands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-28T07:18:11Z","receivedAt":"2009-10-28T07:18:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks.\n"},{"id":"126135","messageId":"40aa078e0910280520t497f1289sf374a3a501856a23@mail.gmail.com","threadId":"21374","inReplyTo":"2faad3050910271405k4a391184vb978b9b35484383b@mail.gmail.com","subject":"Re: possible usability issue in rebase -i?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2009-10-28T12:20:03Z","receivedAt":"2009-10-28T12:20:03Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Tue, Oct 27, 2009 at 10:05 PM, Baz wrote:\n> I'm fine with this way of fixing it, but I'd make a few more changes...\n\nFeel free to make a patch-series that addresses more issues - I'm not going to.\n\nWe make patches of one change at the time in Git. Other (related)\nusability issues becomes separate patches, preferably grouped together\nin a patch-series. This change would be one patch in such a series.\n\n>>  OPTIONS_SPEC=\"\\\n>>  git-rebase [-i] [options] [--] []\n>\n> Use the dashless form and be more consistent with the help - and\n> mention '--root' here, it appears in the\n> help below:\n>\n> -git-rebase [-i] [options] [--] []\n> +git rebase [--interactive | -i] [options] [--onto ] [--]\n> []\n> +git rebase [--interactive | -i] [options] --onto --root\n> [--] []\n>\n\nI'm not sure I follow - aren't dashless options, uhm, dashless? Do you\nmean to use the long-form instead of the short-form? I'll assume\nthat's what you mean for now, since you changed \"-i\" to \"--interactive\n| -i\".\n\nIf so, I'm not 100% convinced it's a clear win: some grep'ing\nindicates that both the short and long form are both widely used, with\nshort-option bein a slight favor:\n$ git grep \" \\[--\" | grep -v \" \\[--\\]\" | wc -l\n 228\n$ git grep \" \\[-[^-]\" | wc -l\n 243\n\nAlso, the usage isn't the only documentation. I think it makes sense\nto try to keep the usage short and to the point, there's a list\ndescribing each option (showing the full-name) further down in the\nusage-message. And if that's not enough, there's the \"git\nhelp\"-command.\n\nIf I've misunderstood you and you only want the usage-string to match\nthat of the manpage, perhaps that might be a good idea. I dunno.\n\n>\n>> -git-rebase [-i] (--continue | --abort | --skip)\n>> +git-rebase [-i] [-m] (--continue | --abort | --skip)\n>\n> Again, dashless. And I'd not mention the useless -i here, the man page\n> doesn't either:\n>\n> -git-rebase [-i] (--continue | --abort | --skip)\n> +git rebase (--continue | --abort | --skip)\n>\n\nIt was already there, so I didn't consider it, but I guess it makes\nsense. Besides, I aimed at not loosing any information while making it\na bit clearer.\n\n> These two items are misplaced in the help (I think). They're not like\n> abort, continue, skip, but then, the man page doesn't group those\n> separately either.\n>\n> +no-verify          override pre-rebase hook from stopping the operation\n> +root               rebase all reachable commmits up to the root(s)\n>\n\nAgree.\n\n>>  Actions:\n>>  continue           continue rebasing process\n>>  abort              abort rebasing process and restore original branch\n>\n> As above, remove the next two lines after your patch:\n>\n> -no-verify          override pre-rebase hook from stopping the operation\n> -root               rebase all reachable commmits up to the root(s)\n\nI don't follow this. Are you repeating yourself now? :)\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"126145","messageId":"2faad3050910280734l7297c30erfb0a47b12b0bd07d@mail.gmail.com","threadId":"21374","inReplyTo":"40aa078e0910280520t497f1289sf374a3a501856a23@mail.gmail.com","subject":"Re: possible usability issue in rebase -i?","fromName":"Baz","fromEmail":"brian.ewins@gmail.com","sentAt":"2009-10-28T14:34:09Z","receivedAt":"2009-10-28T14:34:09Z","isPatch":false,"sender":{"key":"brian.ewins@gmail.com","avatar":"https://gravatar.com/avatar/9ac03d89105e50a7151e695a1b4b1228151064ec3ac380a73b74ab397796baf7?d=mp&s=160"},"body":"2009/10/28 Erik Faye-Lund :\n> On Tue, Oct 27, 2009 at 10:05 PM, Baz wrote:\n>> I'm fine with this way of fixing it, but I'd make a few more changes...\n>\n> Feel free to make a patch-series that addresses more issues - I'm not going to.\n>\n\nYep, I wrote one but had to leave the house before sending it. Later today.\n\n> We make patches of one change at the time in Git. Other (related)\n> usability issues becomes separate patches, preferably grouped together\n> in a patch-series. This change would be one patch in such a series.\n>\n>>>  OPTIONS_SPEC=\"\\\n>>>  git-rebase [-i] [options] [--] []\n>>\n>> Use the dashless form and be more consistent with the help - and\n>> mention '--root' here, it appears in the\n>> help below:\n>>\n>> -git-rebase [-i] [options] [--] []\n>> +git rebase [--interactive | -i] [options] [--onto ] [--]\n>> []\n>> +git rebase [--interactive | -i] [options] --onto --root\n>> [--] []\n>>\n>\n> I'm not sure I follow - aren't dashless options, uhm, dashless? Do you\n> mean to use the long-form instead of the short-form? I'll assume\n> that's what you mean for now, since you changed \"-i\" to \"--interactive\n> | -i\".\n\nNo, I just meant 'git rebase' not 'git-rebase'. Sorry, I changed a\ncouple of things at once.\n\n>\n> If so, I'm not 100% convinced it's a clear win: some grep'ing\n> indicates that both the short and long form are both widely used, with\n> short-option bein a slight favor:\n> $ git grep \" \\[--\" | grep -v \" \\[--\\]\" | wc -l\n>    228\n> $ git grep \" \\[-[^-]\" | wc -l\n>    243\n>\n> Also, the usage isn't the only documentation. I think it makes sense\n> to try to keep the usage short and to the point, there's a list\n> describing each option (showing the full-name) further down in the\n> usage-message. And if that's not enough, there's the \"git\n> help\"-command.\n>\n> If I've misunderstood you and you only want the usage-string to match\n> that of the manpage, perhaps that might be a good idea. I dunno.\n\nIn the patch I've followed other uses of OPTIONS_SPEC; they're quite\nverbose, covering all options, while scripts using USAGE/LONG_USAGE\ntend to emit one-liners. As for calling out 'interactive', at the\nother extreme its not clear to me why we mention '-i' separately from\n'[options]' at all. rebase is already pretty inconsistent here, giving\nshort or long usage messages depending on whether you passed '-i'. But\nI'll take comments on this when I submit the patch, I've no strong\nfeelings on it.\n\n>\n>>\n>>> -git-rebase [-i] (--continue | --abort | --skip)\n>>> +git-rebase [-i] [-m] (--continue | --abort | --skip)\n>>\n>> Again, dashless. And I'd not mention the useless -i here, the man page\n>> doesn't either:\n>>\n>> -git-rebase [-i] (--continue | --abort | --skip)\n>> +git rebase (--continue | --abort | --skip)\n>>\n>\n> It was already there, so I didn't consider it, but I guess it makes\n> sense. Besides, I aimed at not loosing any information while making it\n> a bit clearer.\n>\n>> These two items are misplaced in the help (I think). They're not like\n>> abort, continue, skip, but then, the man page doesn't group those\n>> separately either.\n>>\n>> +no-verify          override pre-rebase hook from stopping the operation\n>> +root               rebase all reachable commmits up to the root(s)\n>>\n>\n> Agree.\n>\n>>>  Actions:\n>>>  continue           continue rebasing process\n>>>  abort              abort rebasing process and restore original branch\n>>\n>> As above, remove the next two lines after your patch:\n>>\n>> -no-verify          override pre-rebase hook from stopping the operation\n>> -root               rebase all reachable commmits up to the root(s)\n>\n> I don't follow this. Are you repeating yourself now? :)\n\nYes :) ... was just finishing off moving those two lines.\n\nCheers,\nBaz\n\n>\n> --\n> Erik \"kusma\" Faye-Lund\n>\n"},{"id":"126146","messageId":"40aa078e0910280741w1656757asbdfab417688f3e8c@mail.gmail.com","threadId":"21374","inReplyTo":"2faad3050910280734l7297c30erfb0a47b12b0bd07d@mail.gmail.com","subject":"Re: possible usability issue in rebase -i?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2009-10-28T14:41:41Z","receivedAt":"2009-10-28T14:41:41Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, Oct 28, 2009 at 3:34 PM, Baz wrote:\n> 2009/10/28 Erik Faye-Lund :\n>> I'm not sure I follow - aren't dashless options, uhm, dashless? Do you\n>> mean to use the long-form instead of the short-form? I'll assume\n>> that's what you mean for now, since you changed \"-i\" to \"--interactive\n>> | -i\".\n>\n> No, I just meant 'git rebase' not 'git-rebase'. Sorry, I changed a\n> couple of things at once.\n\nAh, didn't notice that one. I completely agree with you on this.\n\n> tend to emit one-liners. As for calling out 'interactive', at the\n> other extreme its not clear to me why we mention '-i' separately from\n> '[options]' at all. rebase is already pretty inconsistent here, giving\n> short or long usage messages depending on whether you passed '-i'. But\n> I'll take comments on this when I submit the patch, I've no strong\n> feelings on it.\n\nIt's a simple reason why the output is different - this is the usage\nfor \"git rebase -i\" (hence it is in git-rebase--interactive.sh). I\nguess this distinction would be slightly clearer if we removed the\nbrackets from the usage like this:\n\n-git-rebase [-i] [whatever]\n+git-rebase -i [whatever]\n\n\n-- \nErik \"kusma\" Faye-Lund\n"}]}