{"thread":{"id":"25882","subject":"[PATCH] git-add.txt: Order options alphabetically","startedAt":"2010-12-01T15:42:25Z","lastAt":"2010-12-02T01:36:05Z","messageCount":11,"participants":["jari.aalto@cante.net","Drew Northup","Jari Aalto","Kevin Ballard","SZEDER Gábor"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"156945","messageId":"1291218145-13016-1-git-send-email-jari.aalto@cante.net","threadId":"25882","inReplyTo":null,"subject":"[PATCH] git-add.txt: Order options alphabetically","fromName":"","fromEmail":"jari.aalto@cante.net","sentAt":"2010-12-01T15:42:25Z","receivedAt":"2010-12-01T15:42:25Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"From: Jari Aalto \n\n\nSigned-off-by: Jari Aalto \n---\n Documentation/git-add.txt | 106 ++++++++++++++++++++++----------------------\n 1 files changed, 53 insertions(+), 53 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex 54aaaeb..83751c6 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -46,24 +46,26 @@ be used to add ignored files with the `-f` (force) option.\n Please see linkgit:git-commit[1] for alternative ways to add content to a\n commit.\n \n-\n OPTIONS\n -------\n-...::\n-\tFiles to add content from. Fileglobs (e.g. `*.c`) can\n-\tbe given to add all matching files. Also a\n-\tleading directory name (e.g. `dir` to add `dir/file1`\n-\tand `dir/file2`) can be given to add all files in the\n-\tdirectory, recursively.\n \n--n::\n---dry-run::\n-\tDon't actually add the file(s), just show if they exist and/or will\n-\tbe ignored.\n+-A::\n+--all::\n+\tLike `-u`, but match against files in the\n+\tworking tree in addition to the index. That means that it\n+\twill find new files as well as staging modified content and\n+\tremoving files that are no longer in the working tree.\n \n--v::\n---verbose::\n- Be verbose.\n+-e, \\--edit::\n+\tOpen the diff vs. the index in an editor and let the user\n+\tedit it. After the editor was closed, adjust the hunk headers\n+\tand apply the patch to the index.\n++\n+The intent of this option is to pick and choose lines of the patch to\n+apply, or even to modify the contents of lines to be staged. This can be\n+quicker and more flexible than using the interactive hunk selector.\n+However, it is easy to confuse oneself and create a patch that does not\n+apply to the index. See EDITING PATCHES below.\n \n -f::\n --force::\n@@ -76,6 +78,30 @@ OPTIONS\n \toperation to a subset of the working tree. See ``Interactive\n \tmode'' for details.\n \n+--ignore-errors::\n+\tIf some files could not be added because of errors indexing\n+\tthem, do not abort the operation, but continue adding the\n+\tothers. The command shall still exit with non-zero status.\n+\n+--ignore-missing::\n+\tThis option can only be used together with --dry-run. By using\n+\tthis option the user can check if any of the given files would\n+\tbe ignored, no matter if they are already present in the work\n+\ttree or not.\n+\n+-n::\n+--dry-run::\n+\tDon't actually add the file(s), just show if they exist and/or will\n+\tbe ignored.\n+\n+-N::\n+--intent-to-add::\n+\tRecord only the fact that the path will be added later. An entry\n+\tfor the path is placed in the index with no content. This is\n+\tuseful for, among other things, showing the unstaged content of\n+\tsuch files with `git diff` and committing them with `git commit\n+\t-a`.\n+\n -p::\n --patch::\n \tInteractively choose hunks of patch between the index and the\n@@ -87,16 +113,9 @@ This effectively runs `add --interactive`, but bypasses the\n initial command menu and directly jumps to the `patch` subcommand.\n See ``Interactive mode'' for details.\n \n--e, \\--edit::\n-\tOpen the diff vs. the index in an editor and let the user\n-\tedit it. After the editor was closed, adjust the hunk headers\n-\tand apply the patch to the index.\n-+\n-The intent of this option is to pick and choose lines of the patch to\n-apply, or even to modify the contents of lines to be staged. This can be\n-quicker and more flexible than using the interactive hunk selector.\n-However, it is easy to confuse oneself and create a patch that does not\n-apply to the index. See EDITING PATCHES below.\n+--refresh::\n+\tDon't add the file(s), but only refresh their stat()\n+\tinformation in the index.\n \n -u::\n --update::\n@@ -111,41 +130,22 @@ If no is given, default to \".\"; in other words,\n update all tracked files in the current directory and its\n subdirectories.\n \n--A::\n---all::\n-\tLike `-u`, but match against files in the\n-\tworking tree in addition to the index. That means that it\n-\twill find new files as well as staging modified content and\n-\tremoving files that are no longer in the working tree.\n-\n--N::\n---intent-to-add::\n-\tRecord only the fact that the path will be added later. An entry\n-\tfor the path is placed in the index with no content. This is\n-\tuseful for, among other things, showing the unstaged content of\n-\tsuch files with `git diff` and committing them with `git commit\n-\t-a`.\n-\n---refresh::\n-\tDon't add the file(s), but only refresh their stat()\n-\tinformation in the index.\n-\n---ignore-errors::\n-\tIf some files could not be added because of errors indexing\n-\tthem, do not abort the operation, but continue adding the\n-\tothers. The command shall still exit with non-zero status.\n-\n---ignore-missing::\n-\tThis option can only be used together with --dry-run. By using\n-\tthis option the user can check if any of the given files would\n-\tbe ignored, no matter if they are already present in the work\n-\ttree or not.\n+-v::\n+--verbose::\n+ Be verbose.\n \n \\--::\n \tThis option can be used to separate command-line options from\n \tthe list of files, (useful when filenames might be mistaken\n \tfor command-line options).\n \n+...::\n+\tFiles to add content from. Fileglobs (e.g. `*.c`) can\n+\tbe given to add all matching files. Also a\n+\tleading directory name (e.g. `dir` to add `dir/file1`\n+\tand `dir/file2`) can be given to add all files in the\n+\tdirectory, recursively.\n+\n \n Configuration\n -------------\n-- \n1.7.2.3\n"},{"id":"156982","messageId":"1291229622.11917.14.camel@drew-northup.unet.maine.edu","threadId":"25882","inReplyTo":"1291218145-13016-1-git-send-email-jari.aalto@cante.net","subject":"Re: [PATCH] git-add.txt: Order options alphabetically","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2010-12-01T18:53:42Z","receivedAt":"2010-12-01T18:53:42Z","isPatch":true,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Wed, 2010-12-01 at 17:42 +0200, jari.aalto@cante.net wrote:\n> From: Jari Aalto \n> \n> \n> Signed-off-by: Jari Aalto \n> ---\n> Documentation/git-add.txt | 106 ++++++++++++++++++++++----------------------\n> 1 files changed, 53 insertions(+), 53 deletions(-)\n> \n> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\n> index 54aaaeb..83751c6 100644\n> --- a/Documentation/git-add.txt\n> +++ b/Documentation/git-add.txt\n> @@ -46,24 +46,26 @@ be used to add ignored files with the `-f` (force) option.\n> Please see linkgit:git-commit[1] for alternative ways to add content to a\n> commit.\n> \n> -\n> OPTIONS\n> -------\n> -...::\n> -\tFiles to add content from. Fileglobs (e.g. `*.c`) can\n> -\tbe given to add all matching files. Also a\n> -\tleading directory name (e.g. `dir` to add `dir/file1`\n> -\tand `dir/file2`) can be given to add all files in the\n> -\tdirectory, recursively.\n> \n> --n::\n> ---dry-run::\n> -\tDon't actually add the file(s), just show if they exist and/or will\n> -\tbe ignored.\n> +-A::\n> +--all::\n> +\tLike `-u`, but match against files in the\n> +\tworking tree in addition to the index. That means that it\n> +\twill find new files as well as staging modified content and\n> +\tremoving files that are no longer in the working tree.\n> \n> --v::\n> ---verbose::\n> - Be verbose.\n> +-e, \\--edit::\n> +\tOpen the diff vs. the index in an editor and let the user\n> +\tedit it. After the editor was closed, adjust the hunk headers\n> +\tand apply the patch to the index.\n> ++\n> +The intent of this option is to pick and choose lines of the patch to\n> +apply, or even to modify the contents of lines to be staged. This can be\n> +quicker and more flexible than using the interactive hunk selector.\n> +However, it is easy to confuse oneself and create a patch that does not\n> +apply to the index. See EDITING PATCHES below.\n> \n> -f::\n> --force::\n> @@ -76,6 +78,30 @@ OPTIONS\n> \toperation to a subset of the working tree. See ``Interactive\n> \tmode'' for details.\n> \n> +--ignore-errors::\n> +\tIf some files could not be added because of errors indexing\n> +\tthem, do not abort the operation, but continue adding the\n> +\tothers. The command shall still exit with non-zero status.\n> +\n> +--ignore-missing::\n> +\tThis option can only be used together with --dry-run. By using\n> +\tthis option the user can check if any of the given files would\n> +\tbe ignored, no matter if they are already present in the work\n> +\ttree or not.\n> +\n> +-n::\n> +--dry-run::\n> +\tDon't actually add the file(s), just show if they exist and/or will\n> +\tbe ignored.\n> +\n> +-N::\n> +--intent-to-add::\n> +\tRecord only the fact that the path will be added later. An entry\n> +\tfor the path is placed in the index with no content. This is\n> +\tuseful for, among other things, showing the unstaged content of\n> +\tsuch files with `git diff` and committing them with `git commit\n> +\t-a`.\n> +\n> -p::\n> --patch::\n> \tInteractively choose hunks of patch between the index and the\n> @@ -87,16 +113,9 @@ This effectively runs `add --interactive`, but bypasses the\n> initial command menu and directly jumps to the `patch` subcommand.\n> See ``Interactive mode'' for details.\n> \n> --e, \\--edit::\n> -\tOpen the diff vs. the index in an editor and let the user\n> -\tedit it. After the editor was closed, adjust the hunk headers\n> -\tand apply the patch to the index.\n> -+\n> -The intent of this option is to pick and choose lines of the patch to\n> -apply, or even to modify the contents of lines to be staged. This can be\n> -quicker and more flexible than using the interactive hunk selector.\n> -However, it is easy to confuse oneself and create a patch that does not\n> -apply to the index. See EDITING PATCHES below.\n> +--refresh::\n> +\tDon't add the file(s), but only refresh their stat()\n> +\tinformation in the index.\n> \n> -u::\n> --update::\n> @@ -111,41 +130,22 @@ If no is given, default to \".\"; in other words,\n> update all tracked files in the current directory and its\n> subdirectories.\n> \n> --A::\n> ---all::\n> -\tLike `-u`, but match against files in the\n> -\tworking tree in addition to the index. That means that it\n> -\twill find new files as well as staging modified content and\n> -\tremoving files that are no longer in the working tree.\n> -\n> --N::\n> ---intent-to-add::\n> -\tRecord only the fact that the path will be added later. An entry\n> -\tfor the path is placed in the index with no content. This is\n> -\tuseful for, among other things, showing the unstaged content of\n> -\tsuch files with `git diff` and committing them with `git commit\n> -\t-a`.\n> -\n> ---refresh::\n> -\tDon't add the file(s), but only refresh their stat()\n> -\tinformation in the index.\n> -\n> ---ignore-errors::\n> -\tIf some files could not be added because of errors indexing\n> -\tthem, do not abort the operation, but continue adding the\n> -\tothers. The command shall still exit with non-zero status.\n> -\n> ---ignore-missing::\n> -\tThis option can only be used together with --dry-run. By using\n> -\tthis option the user can check if any of the given files would\n> -\tbe ignored, no matter if they are already present in the work\n> -\ttree or not.\n> +-v::\n> +--verbose::\n> + Be verbose.\n> \n> \\--::\n> \tThis option can be used to separate command-line options from\n> \tthe list of files, (useful when filenames might be mistaken\n> \tfor command-line options).\n> \n> +...::\n> +\tFiles to add content from. Fileglobs (e.g. `*.c`) can\n> +\tbe given to add all matching files. Also a\n> +\tleading directory name (e.g. `dir` to add `dir/file1`\n> +\tand `dir/file2`) can be given to add all files in the\n> +\tdirectory, recursively.\n> +\n> \n> Configuration\n> -------------\n\nJari,\nFirst off, this patch (and set I've seen thus far) has little no commit\nmessage. Second (lacking a commit message to tell me), WHY? Some\nprojects order options alphabetically and some in the order they are\nexpected to be most often used. Other documentation writers just specify\nthe options in the same order they were provided in the synopsis (which\ncan rarely be successfully alphabetized). Some have no order whatsoever.\n\nSo again I ask, why make this change? Did you plan on changing the the\nshort help displayed by git add -h as well?\n\n\n\n-- \n-Drew Northup N1XIM\n AKA RvnPhnx on OPN\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"156988","messageId":"87fwuhuwdu.fsf@picasso.cante.net","threadId":"25882","inReplyTo":"1291229622.11917.14.camel@drew-northup.unet.maine.edu","subject":"Re: [PATCH] git-add.txt: Order options alphabetically","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2010-12-01T19:27:09Z","receivedAt":"2010-12-01T19:27:09Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"2010-12-01 20:53 Drew Northup :\n> On Wed, 2010-12-01 at 17:42 +0200, jari.aalto@cante.net wrote:\n> First off, this patch (and set I've seen thus far) has little no commit\n> message.\n\nThere is no point of making it any longer as it is basically the same\nfor everything. I don't think we want to see long identical copies of\nexplanations over and over in \"git log\".\n\n> Did you plan on changing the the short help displayed by git add -h as\n> well?\n\nDon't know. At this time, I happen to have some free time. But that's a\ngood candidate for followup work.\n\nJari\n"},{"id":"156990","messageId":"87bp55uw96.fsf@picasso.cante.net","threadId":"25882","inReplyTo":"1291229622.11917.14.camel@drew-northup.unet.maine.edu","subject":"Re: [PATCH] git-add.txt: Order options alphabetically","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2010-12-01T19:29:57Z","receivedAt":"2010-12-01T19:29:57Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"2010-12-01 20:53 Drew Northup :\n> (lacking a commit message to tell me), WHY? [alphabetical]\n\nQuoting \n\n - You read from top to bottom, therefore A-Z.\n - GNU project uses it in manual pages. It looks good, it looks\n professional, it looks clean. And it works when searching (= no\n oriantation problems regardless of tools; even when you print on\n paper when you don't have any computerized aids to help your search.).\n\nJari\n"},{"id":"156996","messageId":"1291232706.11917.35.camel@drew-northup.unet.maine.edu","threadId":"25882","inReplyTo":"87bp55uw96.fsf@picasso.cante.net","subject":"Re: [PATCH] git-add.txt: Order options alphabetically","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2010-12-01T19:45:06Z","receivedAt":"2010-12-01T19:45:06Z","isPatch":true,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Wed, 2010-12-01 at 21:29 +0200, Jari Aalto wrote:\n> 2010-12-01 20:53 Drew Northup :\n> > (lacking a commit message to tell me), WHY? [alphabetical]\n> \n> Quoting \n> \n> - You read from top to bottom, therefore A-Z.\n> - GNU project uses it in manual pages. It looks good, it looks\n> professional, it looks clean. And it works when searching (= no\n> oriantation problems regardless of tools; even when you print on\n> paper when you don't have any computerized aids to help your search.).\n> \n> Jari\n\nTHAT belongs in a commit message!!!\n\nAs an aside, you haven't looked at the sed and gawk manpages, have you?\n\nAlphabetic order fairly often looks nice, but it is not always the right\nanswer.\n\n-- \n-Drew Northup N1XIM\n AKA RvnPhnx on OPN\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"156998","messageId":"1291232990.11917.40.camel@drew-northup.unet.maine.edu","threadId":"25882","inReplyTo":"87fwuhuwdu.fsf@picasso.cante.net","subject":"Re: [PATCH] git-add.txt: Order options alphabetically","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2010-12-01T19:49:50Z","receivedAt":"2010-12-01T19:49:50Z","isPatch":true,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Wed, 2010-12-01 at 21:27 +0200, Jari Aalto wrote:\n> 2010-12-01 20:53 Drew Northup :\n> > On Wed, 2010-12-01 at 17:42 +0200, jari.aalto@cante.net wrote:\n> > First off, this patch (and set I've seen thus far) has little no commit\n> > message.\n> \n> There is no point of making it any longer as it is basically the same\n> for everything. I don't think we want to see long identical copies of\n> explanations over and over in \"git log\".\n> \n> > Did you plan on changing the the short help displayed by git add -h as\n> > well?\n> \n> Don't know. At this time, I happen to have some free time. But that's a\n> good candidate for followup work.\n> \n> Jari\n\nFirst, before I reply to your post proper, I am going to echo others on\nthis list--unless you see a good specific reason to prune the CC/reply\nlist please leave it intact and use \"reply all\" and not \"reply to list\"\nhere once a conversation has been started. (Other lists may have\ndifferent conventions, and I am still absorbing some of the ones used\nhere myself...)\n\nThat said, like changes should be grouped together in closely related\npatchsets. It makes life easier for everybody. Don't worry about using\nvirtually the same commit message over and over again if that's what is\nactually appropriate. Junio may very well rebase/restructure patches\nthat need it (I haven't checked to see how often he bothers) and will\ntell you if patch structure is completely out of line or unusable--but\nthat's not the same as others actually reviewing the changes themselves.\n\nSee \n\nMessage-ID: <20101201165043.GF26120@burratino>\n\nThese changes should be a bundle, this bundle should have a \"meta\nmessage\", and each element should have a commit message.\n\n\n-- \n-Drew Northup N1XIM\n AKA RvnPhnx on OPN\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"157030","messageId":"39ABD9CC-45F4-4C2D-8081-56F9681C563C@sb.org","threadId":"25882","inReplyTo":"87bp55uw96.fsf@picasso.cante.net","subject":"Re: [PATCH] git-add.txt: Order options alphabetically","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-12-01T22:04:51Z","receivedAt":"2010-12-01T22:04:51Z","isPatch":true,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Dec 1, 2010, at 11:29 AM, Jari Aalto wrote:\n\n> - You read from top to bottom, therefore A-Z.\n\nWhat does that have to do with anything? Very rarely does it make sense to try\nto read options in alphabetical format. If the reader is, in fact, reading from\ntop-to-bottom straight through, they will certainly appreciate having related\noptions grouped together.\n\n> - GNU project uses it in manual pages. It looks good, it looks\n> professional, it looks clean. And it works when searching (= no\n> oriantation problems regardless of tools; even when you print on\n> paper when you don't have any computerized aids to help your search.).\n\n\"Looks clean\" is not a good reason to reduce clarity in the documentation.\nComprehension and ease-of-readability are far more important than visual\naesthetics.\n\n-Kevin Ballard"},{"id":"157034","messageId":"8739qhuo09.fsf@picasso.cante.net","threadId":"25882","inReplyTo":"1291232706.11917.35.camel@drew-northup.unet.maine.edu","subject":"Re: [PATCH] git-add.txt: Order options alphabetically","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2010-12-01T22:28:06Z","receivedAt":"2010-12-01T22:28:06Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"2010-12-01 21:45 Drew Northup :\n> On Wed, 2010-12-01 at 21:29 +0200, Jari Aalto wrote:\n>\n>> 2010-12-01 20:53 Drew Northup :\n>> > (lacking a commit message to tell me), WHY? [alphabetical]\n>> \n>> Quoting \n>> \n>> - You read from top to bottom, therefore A-Z.\n>> - GNU project uses it in manual pages. It looks good, it looks\n>> professional, it looks clean. And it works when searching (= no\n>> oriantation problems regardless of tools; even when you print on\n>> paper when you don't have any computerized aids to help your search.).\n>> \n>> Jari\n>\n> THAT belongs in a commit message!!!\n\nIt does not. No need to clutter 10's of message that long in there..\n\n> As an aside, you haven't looked at the sed and gawk manpages, have you?\n\nThere are plenty of pages that are bad examples. Let's make ours better.\n\nJari\n"},{"id":"157035","messageId":"87vd3dt9c3.fsf@picasso.cante.net","threadId":"25882","inReplyTo":"39ABD9CC-45F4-4C2D-8081-56F9681C563C@sb.org","subject":"Re: [PATCH] git-add.txt: Order options alphabetically","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2010-12-01T22:30:20Z","receivedAt":"2010-12-01T22:30:20Z","isPatch":true,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"2010-12-02 00:04 Kevin Ballard :\n> On Dec 1, 2010, at 11:29 AM, Jari Aalto wrote:\n> Comprehension and ease-of-readability are far more important than visual\n> aesthetics.\n\nYou can't take that out of equation. The people that read Western\nlanguages, read A-Z. It's built in how we comprehend from start of\nschool education.\n\nJari\n"},{"id":"157037","messageId":"DC499C50-ED15-41FA-9298-FE72E4404648@sb.org","threadId":"25882","inReplyTo":"87vd3dt9c3.fsf@picasso.cante.net","subject":"Re: [PATCH] git-add.txt: Order options alphabetically","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-12-01T22:45:31Z","receivedAt":"2010-12-01T22:45:31Z","isPatch":true,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Dec 1, 2010, at 2:30 PM, Jari Aalto wrote:\n\n> 2010-12-02 00:04 Kevin Ballard :\n>> On Dec 1, 2010, at 11:29 AM, Jari Aalto wrote:\n>> Comprehension and ease-of-readability are far more important than visual\n>> aesthetics.\n> \n> You can't take that out of equation. The people that read Western\n> languages, read A-Z. It's built in how we comprehend from start of\n> school education.\n\nI don't understand what you mean. People search A-Z. They don't read A-Z.\nWhen you have tools to do the searching for you, A-Z ordering no longer\nbecomes useful. In an index, sure, as those are intended for scanning by\nhuman eyes, but as actual documentation it serves no purpose.\n\n-Kevin Ballard\n"},{"id":"157070","messageId":"20101202013605.GA5221@neumann","threadId":"25882","inReplyTo":"8739qhuo09.fsf@picasso.cante.net","subject":"Re: [PATCH] git-add.txt: Order options alphabetically","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2010-12-02T01:36:05Z","receivedAt":"2010-12-02T01:36:05Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Please don't cull Cc list.\n\n\nHi,\n\nOn Thu, Dec 02, 2010 at 12:28:06AM +0200, Jari Aalto wrote:\n> 2010-12-01 21:45 Drew Northup :\n> > On Wed, 2010-12-01 at 21:29 +0200, Jari Aalto wrote:\n> >\n> >> 2010-12-01 20:53 Drew Northup :\n> >> > (lacking a commit message to tell me), WHY? [alphabetical]\n> >> \n> >> Quoting \n> >> \n> >> - You read from top to bottom, therefore A-Z.\n> >> - GNU project uses it in manual pages. It looks good, it looks\n> >> professional, it looks clean. And it works when searching (= no\n> >> oriantation problems regardless of tools; even when you print on\n> >> paper when you don't have any computerized aids to help your search.).\n> >> \n> >> Jari\n> >\n> > THAT belongs in a commit message!!!\n> \n> It does not. No need to clutter 10's of message that long in there..\n\nIt definitely does.\n\nPeople doing 'git log -- Documentation/git-add.txt' in the future will\nwant to see it, just as well as people doing 'git log --\nDocumentation/git-commit.txt', or 'git log --\nDocumentation/git-reset.txt', or ....\n\nHtH,\nGábor\n"}]}