{"thread":{"id":"11859","subject":"[PATCH] git-rebase.sh: Update USAGE string","startedAt":"2008-02-03T20:19:25Z","lastAt":"2008-02-06T01:00:29Z","messageCount":20,"participants":["Jari Aalto","Jakub Narebski","Johannes Schindelin","Junio C Hamano","しらいしななこ","Mike Hommey"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"67256","messageId":"prvd3i9e.fsf@blue.sea.net","threadId":"11859","inReplyTo":null,"subject":"[PATCH] git-rebase.sh: Update USAGE string","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2008-02-03T20:19:25Z","receivedAt":"2008-02-03T20:19:25Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"Present the options in -s|--long (short, long) order.\nMention merge and new whitespace option.\n\nSigned-off-by: Jari Aalto <jari.aalto AT cante.net>\n---\n git-rebase.sh |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex bdcea0e..9c8cf90 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -3,7 +3,7 @@\n # Copyright (c) 2005 Junio C Hamano.\n #\n \n-USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'\n+USAGE='[-i|--interactive] [-v|--verbose] [--whitespace={nowarn|warn|error|error-all|strip}] [-m|--merge] [--onto <newbase>] <upstream> [<branch>]'\n LONG_USAGE='git-rebase replaces <branch> with a new branch of the\n same name.  When the --onto option is provided the new branch starts\n out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>\n-- \n1.5.4-rc5.GIT-dirty\n\n\n\n-- \nWelcome to FOSS revolution: we fix and modify until it shines\n"},{"id":"67259","messageId":"m3prvd68uy.fsf@localhost.localdomain","threadId":"11859","inReplyTo":"prvd3i9e.fsf@blue.sea.net","subject":"Re: [PATCH] git-rebase.sh: Update USAGE string","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-03T21:14:21Z","receivedAt":"2008-02-03T21:14:21Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jari Aalto <jari.aalto@cante.net> writes:\n\n> Present the options in -s|--long (short, long) order.\n\nThis is a good change (but might not make sense without the following\none)...\n\n> Mention merge and new whitespace option.\n\n...and this is not; usage string is now too long.\n\nPlease either use placeholder ([<whitespace>]), or enumerate\nonly short version of commands ([-i] [-v] [-m]) in synopsis,\nor break synopsis into lines 80-column lines max.\n\n> -USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'\n> +USAGE='[-i|--interactive] [-v|--verbose] [--whitespace={nowarn|warn|error|error-all|strip}] [-m|--merge] [--onto <newbase>] <upstream> [<branch>]'\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"67278","messageId":"ir15399p.fsf@blue.sea.net","threadId":"11859","inReplyTo":"prvd3i9e.fsf@blue.sea.net","subject":"[PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2008-02-03T23:33:38Z","receivedAt":"2008-02-03T23:33:38Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"Present the options in -s|--long (short, long) order.\nMention merge and new whitespace option.\n\ned-off-by: Jari Aalto <jari.aalto AT cante.net>\n---\n ***********************************************************************\n Reworked patch (No. 1)\n\n [Jakub Narebski]\n > or break synopsis into lines 80-column lines max.\n\n ***********************************************************************\n\n git-rebase.sh |    5 ++++-\n 1 files changed, 4 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex bdcea0e..6805742 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -3,7 +3,10 @@\n # Copyright (c) 2005 Junio C Hamano.\n #\n \n-USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'\n+USAGE='[-i|--interactive] [-v|--verbose]\n+[--whitespace={nowarn|warn|error|error-all|strip}]\n+[-m|--merge] [--onto <newbase>] <upstream> [<branch>]'\n+\n LONG_USAGE='git-rebase replaces <branch> with a new branch of the\n same name.  When the --onto option is provided the new branch starts\n out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>\n-- \n1.5.4-rc5.GIT-dirty\n\n\n-- \nWelcome to FOSS revolution: we fix and modify until it shines\n"},{"id":"67279","messageId":"alpine.LSU.1.00.0802032340400.7372@racer.site","threadId":"11859","inReplyTo":"ir15399p.fsf@blue.sea.net","subject":"Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-03T23:41:13Z","receivedAt":"2008-02-03T23:41:13Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nwhat's this \"(No. 1)\" business?\n\nOn Mon, 4 Feb 2008, Jari Aalto wrote:\n\n> ed-off-by: Jari Aalto <jari.aalto AT cante.net>\n\ned-by: me... ;-)\n\n> Welcome to FOSS revolution: we fix and modify until it shines\n\n/me grins\n\nCiao,\nDscho\n"},{"id":"67281","messageId":"m3lk6161jo.fsf@localhost.localdomain","threadId":"11859","inReplyTo":"ir15399p.fsf@blue.sea.net","subject":"Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-03T23:52:23Z","receivedAt":"2008-02-03T23:52:23Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jari Aalto <jari.aalto@cante.net> writes:\n\n> Subject: Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)\n\nWhat's with the \"(No. 1)\" here? If you want to add some comment that\nshould *not* be part of commit message, put it in brackets beside\nPATCH, for example \"[PATCH/RFC]\", \"[PATCH (resend)]\", \n\"[PATCH (amend)]\", \"[PATCH v2]\" etc.\n\n> Present the options in -s|--long (short, long) order.\n> Mention merge and new whitespace option.\n> \n> ed-off-by: Jari Aalto <jari.aalto AT cante.net>\n\nI guess that it is copy'n'paste error, and it should be\nSigned-off-by: Jari Aalto <jari.aalto@cante.net>\n\n>  \n> -USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'\n> +USAGE='[-i|--interactive] [-v|--verbose]\n> +[--whitespace={nowarn|warn|error|error-all|strip}]\n\nI would say \"[--whitespace=<option>]\" or \"[--whitespace=<action>]\"\ninstead of introducing yet not agreed upon notation (this has the\nadvantage of shortening synopisis, which should be short IMHO).\n\nBesides here the mutually exclusive options are naturelly delimited,\nso you can say just (I think):\n   [--whitespace=nowarn|warn|error|error-all|strip]\n\n> +[-m|--merge] [--onto <newbase>] <upstream> [<branch>]'\n> +\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"67286","messageId":"zluh1sxv.fsf@blue.sea.net","threadId":"11859","inReplyTo":"m3lk6161jo.fsf@localhost.localdomain","subject":"Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2008-02-04T00:11:40Z","receivedAt":"2008-02-04T00:11:40Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"* Sun 2008-02-03 Jakub Narebski <jnareb@gmail.com> INBOX\n> I would say \"[--whitespace=<option>]\" or \"[--whitespace=<action>]\"\n> instead of introducing yet not agreed upon notation (this has the\n> advantage of shortening synopisis, which should be short IMHO).\n\nThe \"{a|b|c}\" is a used syntax. See cpio(1).\n \n    cpio  {-o|--create} [-0acvABLV] ...\n\nThe information about values to --whitespace is buried under 2 manual\npages. A help that displays the values immediately is more helpful. The\n--whitespace option is used very frequently.\n\nJari\n\n-- \nWelcome to FOSS revolution: we fix and modify until it shines\n"},{"id":"67287","messageId":"ve551spy.fsf@blue.sea.net","threadId":"11859","inReplyTo":"prvd3i9e.fsf@blue.sea.net","subject":"[PATCH v2] git-rebase.sh: Update USAGE string","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2008-02-04T00:16:25Z","receivedAt":"2008-02-04T00:16:25Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"Present the options in -s|--long (short, long) order.\nMention merge and new whitespace option.\n\nSigned-off-by: Jari Aalto <jari.aalto AT cante.net>\n---\n ***********************************************************************\n Reworked patch (No. 2)\n\n * [Jakub Narebski]\n > break synopsis into lines 80-column lines max.\n\n * Fix \"ed-off-by\"\n\n ***********************************************************************\n\n git-rebase.sh |    5 ++++-\n 1 files changed, 4 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex bdcea0e..6805742 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -3,7 +3,10 @@\n # Copyright (c) 2005 Junio C Hamano.\n #\n \n-USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'\n+USAGE='[-i|--interactive] [-v|--verbose]\n+[--whitespace={nowarn|warn|error|error-all|strip}]\n+[-m|--merge] [--onto <newbase>] <upstream> [<branch>]'\n+\n LONG_USAGE='git-rebase replaces <branch> with a new branch of the\n same name.  When the --onto option is provided the new branch starts\n out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>\n-- \n1.5.4-rc5.GIT-dirty\n\n\n\n-- \nWelcome to FOSS revolution: we fix and modify until it shines\n"},{"id":"67288","messageId":"7vodaxpo0i.fsf@gitster.siamese.dyndns.org","threadId":"11859","inReplyTo":"m3lk6161jo.fsf@localhost.localdomain","subject":"Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-04T00:24:13Z","receivedAt":"2008-02-04T00:24:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> Besides here the mutually exclusive options are naturelly delimited,\n> so you can say just (I think):\n>    [--whitespace=nowarn|warn|error|error-all|strip]\n\nI think that is probably the right thing to do in this case.  It\nis clear where the alternatives end, without adding extra\ngrouping, so it keeps the description easy to read.\n\nIt may fail with a sick reader who would complain \"but 'git\nrebase --whitespace=nowarn' is correct while 'git rebase warn'\nis not!\", but personally I do not think we deeply care about\npleasing such a pedantic nitpicker.\n"},{"id":"67291","messageId":"alpine.LSU.1.00.0802040026010.7372@racer.site","threadId":"11859","inReplyTo":"zluh1sxv.fsf@blue.sea.net","subject":"Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-04T00:27:30Z","receivedAt":"2008-02-04T00:27:30Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 4 Feb 2008, Jari Aalto wrote:\n\n> * Sun 2008-02-03 Jakub Narebski <jnareb@gmail.com> INBOX\n> > I would say \"[--whitespace=<option>]\" or \"[--whitespace=<action>]\"\n> > instead of introducing yet not agreed upon notation (this has the\n> > advantage of shortening synopisis, which should be short IMHO).\n> \n> The \"{a|b|c}\" is a used syntax. See cpio(1).\n\nBy this reasoning, \"(a|b|c)\" is also a used syntax.  See git-branch(1).\n\nCiao,\nDscho\n"},{"id":"67294","messageId":"7vfxw9pnbp.fsf@gitster.siamese.dyndns.org","threadId":"11859","inReplyTo":"zluh1sxv.fsf@blue.sea.net","subject":"Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-04T00:39:06Z","receivedAt":"2008-02-04T00:39:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jari Aalto <jari.aalto@cante.net> writes:\n\n> * Sun 2008-02-03 Jakub Narebski <jnareb@gmail.com> INBOX\n>> I would say \"[--whitespace=<option>]\" or \"[--whitespace=<action>]\"\n>> instead of introducing yet not agreed upon notation (this has the\n>> advantage of shortening synopisis, which should be short IMHO).\n>\n> The \"{a|b|c}\" is a used syntax. See cpio(1).\n>  \n>     cpio  {-o|--create} [-0acvABLV] ...\n\nI do not think using {} for grouping is incorrect, and I think\nthere is at least a consensus on the list that it is Ok as long\nas we consistently do so.\n\nUnfortunately, the majority of, if not all of, our existing\ndocuments use () instead for that purpose.\n\nSo pros-and-cons are that (1) changing all of them to use {} is\nmore politically correct (pro); (2) our use of (), as we\nconsistently use them, does not hurt readability (neutral); and\n(3) it is a thankless makework to replace them all to {} _and\nmake sure the conversion is correct_ (large con).  (4) also if\nother people make changes to documentation at the same time,\nthat would add more work in conflict resolution (slight con).\n\nAs you seem to have volunteered to do the conversion and\nvalidation, I do not see much problem to move from () to {} in\nprinciple.\n\nAbout the part your patch touches, [--whitespace={a|b|c}] is\nmore precise than [--whitespace=a|b|c] Jakub suggested, but I\nsuspect most sane people would not misinterpret the latter as\n\"this part can be omitted but you could write '--whitespace=a',\n'b' or 'c' here\", so...\n"},{"id":"67331","messageId":"ir15171q.fsf_-_@blue.sea.net","threadId":"11859","inReplyTo":"7vodaxpo0i.fsf@gitster.siamese.dyndns.org","subject":"[PATCH v3] git-rebase.sh: Update USAGE string","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2008-02-04T08:04:33Z","receivedAt":"2008-02-04T08:04:33Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"Present the options in -s|--long (short, long) order.\nMention merge and new whitespace option.\n\nSigned-off-by: Jari Aalto <jari.aalto AT cante.net>\n---\n ***********************************************************************\n reworked patch (No. 3)\n ***********************************************************************\n\n [Junio C Hamano}\n >>    [--whitespace=nowarn|warn|error|error-all|strip]\n >\n > I think that is probably the right thing to do in this case.  It\n > is clear where the alternatives end, without adding extra\n > grouping, so it keeps the description easy to read.\n\n git-rebase.sh |    5 ++++-\n 1 files changed, 4 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex bdcea0e..6128455 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -3,7 +3,10 @@\n # Copyright (c) 2005 Junio C Hamano.\n #\n \n-USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'\n+USAGE='[-i|--interactive] [-v|--verbose]\n+[--whitespace=nowarn|warn|error|error-all|strip]\n+[-m|--merge] [--onto <newbase>] <upstream> [<branch>]'\n+\n LONG_USAGE='git-rebase replaces <branch> with a new branch of the\n same name.  When the --onto option is provided the new branch starts\n out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>\n-- \n1.5.4-rc5.GIT-dirty\n"},{"id":"67342","messageId":"200802041115.22409.jnareb@gmail.com","threadId":"11859","inReplyTo":"7vfxw9pnbp.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-04T10:15:20Z","receivedAt":"2008-02-04T10:15:20Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jari Aalto <jari.aalto@cante.net> writes:\n> \n>> * Sun 2008-02-03 Jakub Narebski <jnareb@gmail.com> INBOX\n>>> I would say \"[--whitespace=<option>]\" or \"[--whitespace=<action>]\"\n>>> instead of introducing yet not agreed upon notation (this has the\n>>> advantage of shortening synopisis, which should be short IMHO).\n>>\n>> The \"{a|b|c}\" is a used syntax. See cpio(1).\n>>  \n>>     cpio  {-o|--create} [-0acvABLV] ...\n\nBTW. it is not only cpio and rpm, but also combinediff (and friends from \npatchutils), flex, gimp, jpegtopnm (and other from netpbm), ps2pdf, \nrun, tail, xmlto, ip, losetup, netstat, sudo and sudoedit,...\n\n> I do not think using {} for grouping is incorrect, and I think\n> there is at least a consensus on the list that it is Ok as long\n> as we consistently do so.\n> \n> Unfortunately, the majority of, if not all of, our existing\n> documents use () instead for that purpose.\n> \n> So pros-and-cons are that (1) changing all of them to use {} is\n> more politically correct (pro); (2) our use of (), as we\n> consistently use them, does not hurt readability (neutral); and\n\nActually we are not entirely consistent here.  git-init(1) has \n  --shared[={false|true|umask|group|all|world|everybody}]\nin the option description, git-rev-list(1) has\n  [ --date={local|relative|default|iso|rfc|short} ]\nin its longish synopsis (although in second case we could omit\nthe curlies, it is in separate line so reducing line length does\nnot matter in this case).\n\n> (3) it is a thankless makework to replace them all to {} _and\n> make sure the conversion is correct_ (large con).  \n\nAll true.\n\n> (4) also if \n> other people make changes to documentation at the same time,\n> that would add more work in conflict resolution (slight con).\n\nWell, we sould have to document this in CodingStyle, I think, then.\n \n> About the part your patch touches, [--whitespace={a|b|c}] is\n> more precise than [--whitespace=a|b|c] Jakub suggested, but I\n> suspect most sane people would not misinterpret the latter as\n> \"this part can be omitted but you could write '--whitespace=a',\n> 'b' or 'c' here\", so...\n\nIt probably also depends if we deperately want to reduce line length as \nnot to split synopsis into yet another line (the shorter synopsis is, \nusually the better).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"67348","messageId":"200802041113.m14BDLMl004301@mi1.bluebottle.com","threadId":"11859","inReplyTo":"m3lk6161jo.fsf@localhost.localdomain","subject":"Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"しらいしななこ","fromEmail":"nanako3@bluebottle.com","sentAt":"2008-02-04T11:12:59Z","receivedAt":"2008-02-04T11:12:59Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Jakub Narebski <jnareb@gmail.com>:\n\n> Jari Aalto <jari.aalto@cante.net> writes:\n>>  \n>> -USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'\n>> +USAGE='[-i|--interactive] [-v|--verbose]\n>> +[--whitespace={nowarn|warn|error|error-all|strip}]\n>\n> I would say \"[--whitespace=<option>]\" or \"[--whitespace=<action>]\"\n> instead of introducing yet not agreed upon notation (this has the\n> advantage of shortening synopisis, which should be short IMHO).\n>\n> Besides here the mutually exclusive options are naturelly delimited,\n> so you can say just (I think):\n>    [--whitespace=nowarn|warn|error|error-all|strip]\n>\n>> +[-m|--merge] [--onto <newbase>] <upstream> [<branch>]'\n>> +\n\nI tried to run \"git rebase --interactive --whitespace=strip\" but it does not seem to strip blank characters at the end of my lines.  Did I find a bug?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n\n----------------------------------------------------------------------\nFind out how you can get spam free email.\nhttp://www.bluebottle.com/tag/3\n"},{"id":"67349","messageId":"20080204115741.GA23834@glandium.org","threadId":"11859","inReplyTo":"200802041115.22409.jnareb@gmail.com","subject":"Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-02-04T11:57:42Z","receivedAt":"2008-02-04T11:57:42Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Feb 04, 2008 at 11:15:20AM +0100, Jakub Narebski <jnareb@gmail.com> wrote:\n> Actually we are not entirely consistent here.  git-init(1) has \n>   --shared[={false|true|umask|group|all|world|everybody}]\n> in the option description, git-rev-list(1) has\n>   [ --date={local|relative|default|iso|rfc|short} ]\n\nWhat is inconsistent here ? The first tells you you can use --shared without\nan argument. And it's [--shared[=<permissions>]] in the synopsis, so you\nmay omit --shared, or use in alone, or specify permissions. The second tells\nyou can't use --date without an additional argument.\n\nMike\n"},{"id":"67357","messageId":"200802041353.25592.jnareb@gmail.com","threadId":"11859","inReplyTo":"20080204115741.GA23834@glandium.org","subject":"Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-04T12:53:23Z","receivedAt":"2008-02-04T12:53:23Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 4 Feb 2008, Mike Hommey wrote:\n> On Mon, Feb 04, 2008 at 11:15:20AM +0100, Jakub Narebski <jnareb@gmail.com> wrote:\n>> Junio C Hamano wrote:\n\n>>> Unfortunately, the majority of, if not all of, our existing\n>>> documents use () instead for that purpose.\n>>>\n>>> So pros-and-cons are that [...] (2) our use of (), as we\n>>> consistently use them, does not hurt readability (neutral); and\n\nThe above was re-added by me.\n\n>> Actually we are not entirely consistent here.  git-init(1) has \n>>   --shared[={false|true|umask|group|all|world|everybody}]\n>> in the option description, git-rev-list(1) has\n>>   [ --date={local|relative|default|iso|rfc|short} ]\n> \n> What is inconsistent here ? The first tells you you can use --shared without\n> an argument. And it's [--shared[=<permissions>]] in the synopsis, so you\n> may omit --shared, or use in alone, or specify permissions. The second tells\n> you can't use --date without an additional argument.\n\nYou have cut a bit too much when quoting. The inconsistency is between\ngit-branch(1) using () to delimit mutually exclusive options:\n\n   git-branch (-m | -M) [<oldbranch>] <newbranch>\n\nand git-init(1) (and git-rev-list(1)) using {} for that:\n\n   --shared[={false|true|umask|group|all|world|everybody}]\n\n-- \nJakub Narebski\nPoland\n"},{"id":"67371","messageId":"alpine.LSU.1.00.0802041505230.7372@racer.site","threadId":"11859","inReplyTo":"200802041113.m14BDLMl004301@mi1.bluebottle.com","subject":"rebase -i and --whitespace, was Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-04T15:06:52Z","receivedAt":"2008-02-04T15:06:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 4 Feb 2008, しらいしななこ wrote:\n\n> I tried to run \"git rebase --interactive --whitespace=strip\" but it does \n> not seem to strip blank characters at the end of my lines.  Did I find a \n> bug?\n\nYes.  Interactive rebase never bothered with --whitespace options, since \nit works purely with cherry-pick (the --merge option to non-interactive \nrebase).  Therefore, the operation is not patch based, and does not call \ngit-apply at all (which would handle the whitespace).\n\nCiao,\nDscho\n"},{"id":"67375","messageId":"200802041642.52088.jnareb@gmail.com","threadId":"11859","inReplyTo":"alpine.LSU.1.00.0802041505230.7372@racer.site","subject":"Re: rebase -i and --whitespace, was Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-04T15:42:50Z","receivedAt":"2008-02-04T15:42:50Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W poniedziałek 4. lutego 2008 16:06, Johannes Schindelin napisał:\n> On Mon, 4 Feb 2008, しらいしななこ wrote:\n> \n> > I tried to run \"git rebase --interactive --whitespace=strip\" but it does \n> > not seem to strip blank characters at the end of my lines.  Did I find a \n> > bug?\n> \n> Yes.  Interactive rebase never bothered with --whitespace options, since \n> it works purely with cherry-pick (the --merge option to non-interactive \n> rebase).  Therefore, the operation is not patch based, and does not call \n> git-apply at all (which would handle the whitespace).\n\nSo it means that synopsis should, instead of current (pre-patch)\n\n'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]\n        [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]\n        [--onto <newbase>] <upstream> [<branch>]\n\nshould read\n\n'git-rebase' [-v | --verbose]  [-p | --preserve-merges]\n        [{-i | --interactive} | [-C<n>] [ --whitespace=<option>] [-m | --merge]]\n        [--onto <newbase>] <upstream> [<branch>]\n\nor perhaps even separated into interactive / non-interactive merge?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"67377","messageId":"alpine.LSU.1.00.0802041629140.7372@racer.site","threadId":"11859","inReplyTo":"200802041642.52088.jnareb@gmail.com","subject":"Re: rebase -i and --whitespace, was Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-04T16:32:11Z","receivedAt":"2008-02-04T16:32:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 4 Feb 2008, Jakub Narebski wrote:\n\n> W poniedziałek 4. lutego 2008 16:06, Johannes Schindelin napisał:\n> > On Mon, 4 Feb 2008, しらいしななこ wrote:\n> > \n> > > I tried to run \"git rebase --interactive --whitespace=strip\" but it does \n> > > not seem to strip blank characters at the end of my lines.  Did I find a \n> > > bug?\n> > \n> > Yes.  Interactive rebase never bothered with --whitespace options, since \n> > it works purely with cherry-pick (the --merge option to non-interactive \n> > rebase).  Therefore, the operation is not patch based, and does not call \n> > git-apply at all (which would handle the whitespace).\n> \n> So it means that synopsis should, instead of current (pre-patch)\n> \n> 'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]\n>         [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]\n>         [--onto <newbase>] <upstream> [<branch>]\n> \n> should read\n> \n> 'git-rebase' [-v | --verbose]  [-p | --preserve-merges]\n>         [{-i | --interactive} | [-C<n>] [ --whitespace=<option>] [-m | --merge]]\n>         [--onto <newbase>] <upstream> [<branch>]\n> \n> or perhaps even separated into interactive / non-interactive merge?\n\nOr the --merge code path should check if there was any --whitespace \noption, and re-apply each commit using something like\n\n\tgit reset --hard HEAD^ &&\n\tgit diff-tree HEAD@{1}..HEAD |\n\tgit apply --index <whitespace options>\n\nCiao,\nDscho\n"},{"id":"67586","messageId":"7vir137yvx.fsf@gitster.siamese.dyndns.org","threadId":"11859","inReplyTo":"200802041642.52088.jnareb@gmail.com","subject":"Re: rebase -i and --whitespace, was Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-05T23:43:30Z","receivedAt":"2008-02-05T23:43:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n> So it means that synopsis should, instead of current (pre-patch)\n>\n> 'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]\n>         [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]\n>         [--onto <newbase>] <upstream> [<branch>]\n>\n> should read\n>\n> 'git-rebase' [-v | --verbose]  [-p | --preserve-merges]\n>         [{-i | --interactive} | [-C<n>] [ --whitespace=<option>] [-m | --merge]]\n>         [--onto <newbase>] <upstream> [<branch>]\n>\n> or perhaps even separated into interactive / non-interactive merge?\n\nI think the reality is:\n\n * -i ignores the lack of -m (i.e. do not use the slow \"merge\");\n\n * Rebase with -m cannot use -C<n> and --whitespace (hence -i\n   because it forces -m);\n\n * -p is only meaningful when using -m;\n\nThree possible courses of actions are:\n\n (1) fix merge codepath (this is involved --- we would need to\n     teach xdl_merge() to honor --whitespace={warn|error|fix}\n     and -C<n>); or\n\n (2) fix -i so that it does not force -m; or\n\n (3) adjust the description to reality.\n\nObviously the easiest would be to document the behaviour as-is,\nbut I suspect (2) would be the best practical solution if we\nwanted to have any improvement compared to the current\nsituation.\n"},{"id":"67595","messageId":"alpine.LSU.1.00.0802060058550.8543@racer.site","threadId":"11859","inReplyTo":"7vir137yvx.fsf@gitster.siamese.dyndns.org","subject":"Re: rebase -i and --whitespace, was Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-06T01:00:29Z","receivedAt":"2008-02-06T01:00:29Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 5 Feb 2008, Junio C Hamano wrote:\n\n> Jakub Narebski <jnareb@gmail.com> writes:\n> \n> > So it means that synopsis should, instead of current (pre-patch)\n> >\n> > 'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]\n> >         [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]\n> >         [--onto <newbase>] <upstream> [<branch>]\n> >\n> > should read\n> >\n> > 'git-rebase' [-v | --verbose]  [-p | --preserve-merges]\n> >         [{-i | --interactive} | [-C<n>] [ --whitespace=<option>] [-m | --merge]]\n> >         [--onto <newbase>] <upstream> [<branch>]\n> >\n> > or perhaps even separated into interactive / non-interactive merge?\n> \n> I think the reality is:\n> \n>  * -i ignores the lack of -m (i.e. do not use the slow \"merge\");\n> \n>  * Rebase with -m cannot use -C<n> and --whitespace (hence -i\n>    because it forces -m);\n> \n>  * -p is only meaningful when using -m;\n\nEven worse, AFAIR -p only works with -i.\n\n> Three possible courses of actions are:\n> \n>  (1) fix merge codepath (this is involved --- we would need to\n>      teach xdl_merge() to honor --whitespace={warn|error|fix}\n>      and -C<n>); or\n> \n>  (2) fix -i so that it does not force -m; or\n> \n>  (3) adjust the description to reality.\n> \n> Obviously the easiest would be to document the behaviour as-is,\n> but I suspect (2) would be the best practical solution if we\n> wanted to have any improvement compared to the current\n> situation.\n\nGranted.  A long time ago, I started making a builtin from rebase/am, but \nI got sidetracked pretty early.\n\nHowever, I think that (2) and builtinification are pretty related, and can \nbe done in one go.\n\nCiao,\nDscho\n"}]}