{"thread":{"id":"46482","subject":"Guidlines for error messages","startedAt":"2017-07-29T02:57:33Z","lastAt":"2017-07-29T03:57:46Z","messageCount":2,"participants":["Kaartic Sivaraam","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"325238","messageId":"1501297078.2711.2.camel@gmail.com","threadId":"46482","inReplyTo":null,"subject":"Guidlines for error messages","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-29T02:57:58Z","receivedAt":"2017-07-29T02:57:33Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hello all,\n\nOn reading the CodingGuidelines, I saw a section that specifies rules\nabout the structure and formatting of error messages. I have reproduced\nit below,\n\n\n    Error Messages\n\n     - Do not end error messages with a full stop.\n\n     - Do not capitalize (\"unable to open %s\", not \"Unable to open %s\")\n\n     - Say what the error is first (\"cannot open %s\", not \"%s: cannot open\")\n\n\nHaving used git all these days, I have seen error messages that do seem\nto be violating the above guidelines (at least the first 2 points). A\nfew are,\n\n\n    Aborting commit due to empty commit message.\n\n\n    fatal: There is no merge to abort (MERGE_HEAD missing).\n\n\n    fatal: You have not concluded your merge (MERGE_HEAD exists).\n    Please, commit your changes before you merge.\n\n\n    error: Empty commit message.\n    Not committing merge; use 'git commit' to complete the merge.\n\n\n    error: pathspec 'hell' did not match any file(s) known to git.\n\n\n    fatal: Not a valid object name foo\n\n\n    fatal: ambiguous argument 'foo..bar': unknown revision or path not in the working tree.\n    Use '--' to separate paths from revisions, like this:\n    'git <command> [<revision>...] -- [<file>...]'\n\n\nA few that do seem to be following the guideline are\n\n    fatal: could not read log file 'imaginary_file': No such file or directory\n\n    fatal: no input file given for in-place editing\n\n\n\n    That makes me wonder, has the guideline changed ?\n    Is this something that must be fixed ?\n    Am I missing something ?\n\n    -- \n    Kaartic\n"},{"id":"325240","messageId":"xmqqa83nlwst.fsf@gitster.mtv.corp.google.com","threadId":"46482","inReplyTo":"1501297078.2711.2.camel@gmail.com","subject":"Re: Guidlines for error messages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-29T03:57:38Z","receivedAt":"2017-07-29T03:57:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:\n\n> On reading the CodingGuidelines, I saw a section that specifies rules\n> about the structure ...\n> ...\n>     That makes me wonder, has the guideline changed ?\n>     Is this something that must be fixed ?\n>     Am I missing something ?\n\nThis applies not just to the message format but with ANY guideline\nwe have around here.\n\nAs we did not have perfect foresight when we started the project,\nthe guidelines grew out of the best practice we learned over time.\nWe try to catch violations for new code during the review process,\nso that we won't add violators, but we do _not_ actively hunt for\nexisting violators and change them _only_ to fix them, which is\nunneeded code churn.  Instead, over time as people notice, most\noften while doing a real work in the vicinity of the code that has\nviolations, we fix them as preparatory clean-up patches before the\nreal work happens.\n"}]}