{"thread":{"id":"54135","subject":"[PATCH] pretty-options.txt: fix --no-abbrev-commit description","startedAt":"2020-08-26T14:51:41Z","lastAt":"2020-08-27T04:32:49Z","messageCount":6,"participants":["Sergey Organov","Junio C Hamano","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"404519","messageId":"20200826144923.16806-1-sorganov@gmail.com","threadId":"54135","inReplyTo":null,"subject":"[PATCH] pretty-options.txt: fix --no-abbrev-commit description","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2020-08-26T14:49:23Z","receivedAt":"2020-08-26T14:51:41Z","isPatch":true,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Description suggested --no-abbrev-commit negates --oneline as well as any other\noption that implies --abbrev-commit. Fix it to say that it's --abbrev-commit\nthat is negated, not the option that implies it.\n\nSigned-off-by: Sergey Organov <sorganov@gmail.com>\n---\n Documentation/pretty-options.txt | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt\nindex 7a6da6db780e..17c5aac4b71d 100644\n--- a/Documentation/pretty-options.txt\n+++ b/Documentation/pretty-options.txt\n@@ -25,8 +25,8 @@ people using 80-column terminals.\n \n --no-abbrev-commit::\n \tShow the full 40-byte hexadecimal commit object name. This negates\n-\t`--abbrev-commit` and those options which imply it such as\n-\t\"--oneline\". It also overrides the `log.abbrevCommit` variable.\n+\t`--abbrev-commit`, either explicit or implied by other options such\n+\tas \"--oneline\". It also overrides the `log.abbrevCommit` variable.\n \n --oneline::\n \tThis is a shorthand for \"--pretty=oneline --abbrev-commit\"\n-- \n2.25.1\n\n"},{"id":"404541","messageId":"xmqqv9h5uw7u.fsf@gitster.c.googlers.com","threadId":"54135","inReplyTo":"20200826144923.16806-1-sorganov@gmail.com","subject":"Re: [PATCH] pretty-options.txt: fix --no-abbrev-commit description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-26T17:56:53Z","receivedAt":"2020-08-26T17:57:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergey Organov <sorganov@gmail.com> writes:\n\n>  --no-abbrev-commit::\n>  \tShow the full 40-byte hexadecimal commit object name. This negates\n> -\t`--abbrev-commit` and those options which imply it such as\n> -\t\"--oneline\". It also overrides the `log.abbrevCommit` variable.\n> +\t`--abbrev-commit`, either explicit or implied by other options such\n> +\tas \"--oneline\". It also overrides the `log.abbrevCommit` variable.\n\nI personally do not think it would be crazy to misread that one-line\nformat itself would be defeated when no abbreviation of object names\nis requested, so from that point of view, the original text would be\nOK enough, but as long as the updated text is easier to understand,\nthat is fine ;-)\n\nKeeping the original sentence structure, e.g.\n\n    ... and those options which imply abbreviating commit object\n    names such as ...\n\nwould have been what I wrote, instead of \"either explicit or implied\nby\", though.\n\nThanks.\n"},{"id":"404555","messageId":"87pn7d9inu.fsf@osv.gnss.ru","threadId":"54135","inReplyTo":"xmqqv9h5uw7u.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] pretty-options.txt: fix --no-abbrev-commit description","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2020-08-26T21:55:17Z","receivedAt":"2020-08-26T21:55:24Z","isPatch":true,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Sergey Organov <sorganov@gmail.com> writes:\n>\n>>  --no-abbrev-commit::\n>>  \tShow the full 40-byte hexadecimal commit object name. This negates\n>> -\t`--abbrev-commit` and those options which imply it such as\n>> -\t\"--oneline\". It also overrides the `log.abbrevCommit` variable.\n>> +\t`--abbrev-commit`, either explicit or implied by other options such\n>> +\tas \"--oneline\". It also overrides the `log.abbrevCommit` variable.\n>\n> I personally do not think it would be crazy to misread that one-line\n> format itself would be defeated when no abbreviation of object names\n> is requested, so from that point of view, the original text would be\n> OK enough,\n\nWell, I don't think it's OK to essentially say:\n\n  \"--no-abbrev-commit\" negates \"--oneline\"\n\nwhen it doesn't. Yes, I even actually checked it doesn't, just in case.\n\n> but as long as the updated text is easier to understand,\n> that is fine ;-)\n\nAdmittedly, not being a native speaker, I'm not sure the form I used is\na good English, but at least it's factually correct.\n\nActually, I'd drop it altogether, to read like this:\n\n--no-abbrev-commit::\n\tShow the full 40-byte hexadecimal commit object name. This negates\n\t`--abbrev-commit` as well as overrides the `log.abbrevCommit` variable.\n\n\nas I don't see why such clarification is at all needed in the first\nplace.\n\nI'll re-roll if you agree this variant is better.\n\n>\n> Keeping the original sentence structure, e.g.\n>\n>     ... and those options which imply abbreviating commit object names\n>     such as ...\n>\n> would have been what I wrote, instead of \"either explicit or implied\n> by\", though.\n\nSorry, but it'd then read:\n\n  This negates `--abbrev-commit` and those options which imply\n  abbreviating commit object names such as \"--oneline\".\n\nthat again essentially reduces to:\n\n  This negates \"--oneline\"\n\nthat is simply false statement, being exactly the problem of the\noriginal that the patch tries to fix.\n\nThanks,\n-- Sergey\n"},{"id":"404556","messageId":"xmqqr1rtt613.fsf@gitster.c.googlers.com","threadId":"54135","inReplyTo":"87pn7d9inu.fsf@osv.gnss.ru","subject":"Re: [PATCH] pretty-options.txt: fix --no-abbrev-commit description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-26T22:07:52Z","receivedAt":"2020-08-26T22:08:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergey Organov <sorganov@gmail.com> writes:\n\n>> Keeping the original sentence structure, e.g.\n>>\n>>     ... and those options which imply abbreviating commit object names\n>>     such as ...\n>>\n>> would have been what I wrote, instead of \"either explicit or implied\n>> by\", though.\n>\n> Sorry, but it'd then read:\n>\n>   This negates `--abbrev-commit` and those options which imply\n>   abbreviating commit object names such as \"--oneline\".\n>\n> that again essentially reduces to:\n>\n>   This negates \"--oneline\"\n\n\"--oneline\" means a lot more than \"do not use full object name\", and\nI think we are on the same page with our shared goal of not negating\neverything \"--oneline\" means.  We just want to say the option\nnegates only the \"do not use full object name\" aspect.\n\n\"and the effect of abbreviating commit objects implied by other\noptions, such as '--oneline'\" may be a more verbose way to say the\nsame thing, I would think, but that would be overkill.  I would have\nexpected that with common sense readers would think it would be\ncrazy for --no-abbrev to override everything --oneline means, but if\nyou found that the original risks such an interpretation, perhaps we\nwould need to be more verbose and explicit.  I dunno.\n\n\n\n"},{"id":"404576","messageId":"20200827042530.GE3346457@coredump.intra.peff.net","threadId":"54135","inReplyTo":"xmqqr1rtt613.fsf@gitster.c.googlers.com","subject":"Re: [PATCH] pretty-options.txt: fix --no-abbrev-commit description","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-08-27T04:25:30Z","receivedAt":"2020-08-27T04:25:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 26, 2020 at 03:07:52PM -0700, Junio C Hamano wrote:\n\n> Sergey Organov <sorganov@gmail.com> writes:\n> \n> >> Keeping the original sentence structure, e.g.\n> >>\n> >>     ... and those options which imply abbreviating commit object names\n> >>     such as ...\n> >>\n> >> would have been what I wrote, instead of \"either explicit or implied\n> >> by\", though.\n> >\n> > Sorry, but it'd then read:\n> >\n> >   This negates `--abbrev-commit` and those options which imply\n> >   abbreviating commit object names such as \"--oneline\".\n> >\n> > that again essentially reduces to:\n> >\n> >   This negates \"--oneline\"\n> \n> \"--oneline\" means a lot more than \"do not use full object name\", and\n> I think we are on the same page with our shared goal of not negating\n> everything \"--oneline\" means.  We just want to say the option\n> negates only the \"do not use full object name\" aspect.\n> \n> \"and the effect of abbreviating commit objects implied by other\n> options, such as '--oneline'\" may be a more verbose way to say the\n> same thing, I would think, but that would be overkill.  I would have\n> expected that with common sense readers would think it would be\n> crazy for --no-abbrev to override everything --oneline means, but if\n> you found that the original risks such an interpretation, perhaps we\n> would need to be more verbose and explicit.  I dunno.\n\nFWIW, as a third-party observer (because you wanted more opinions,\nright?), I found the result of Sergey's original patch easy to read and\nunderstand.\n\nI also think it's unlikely for people to misinterpret the current text,\nbut it does not hurt to be more precise just in case.\n\n-Peff\n"},{"id":"404580","messageId":"xmqqd03cso7o.fsf@gitster.c.googlers.com","threadId":"54135","inReplyTo":"20200827042530.GE3346457@coredump.intra.peff.net","subject":"Re: [PATCH] pretty-options.txt: fix --no-abbrev-commit description","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-27T04:32:43Z","receivedAt":"2020-08-27T04:32:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Aug 26, 2020 at 03:07:52PM -0700, Junio C Hamano wrote:\n>\n>> Sergey Organov <sorganov@gmail.com> writes:\n>> \n>> >> Keeping the original sentence structure, e.g.\n>> >>\n>> >>     ... and those options which imply abbreviating commit object names\n>> >>     such as ...\n>> >>\n>> >> would have been what I wrote, instead of \"either explicit or implied\n>> >> by\", though.\n>> >\n>> > Sorry, but it'd then read:\n>> >\n>> >   This negates `--abbrev-commit` and those options which imply\n>> >   abbreviating commit object names such as \"--oneline\".\n>> >\n>> > that again essentially reduces to:\n>> >\n>> >   This negates \"--oneline\"\n>> \n>> \"--oneline\" means a lot more than \"do not use full object name\", and\n>> I think we are on the same page with our shared goal of not negating\n>> everything \"--oneline\" means.  We just want to say the option\n>> negates only the \"do not use full object name\" aspect.\n>> \n>> \"and the effect of abbreviating commit objects implied by other\n>> options, such as '--oneline'\" may be a more verbose way to say the\n>> same thing, I would think, but that would be overkill.  I would have\n>> expected that with common sense readers would think it would be\n>> crazy for --no-abbrev to override everything --oneline means, but if\n>> you found that the original risks such an interpretation, perhaps we\n>> would need to be more verbose and explicit.  I dunno.\n>\n> FWIW, as a third-party observer (because you wanted more opinions,\n> right?), I found the result of Sergey's original patch easy to read and\n> understand.\n>\n> I also think it's unlikely for people to misinterpret the current text,\n> but it does not hurt to be more precise just in case.\n\nYup, I think I said the same already ;-)\n"}]}