Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> writes: > >> --no-abbrev-commit:: >> Show the full 40-byte hexadecimal commit object name. This negates >> - `--abbrev-commit` and those options which imply it such as >> - "--oneline". It also overrides the `log.abbrevCommit` variable. >> + `--abbrev-commit`, either explicit or implied by other options such >> + as "--oneline". It also overrides the `log.abbrevCommit` variable. > > I personally do not think it would be crazy to misread that one-line > format itself would be defeated when no abbreviation of object names > is requested, so from that point of view, the original text would be > OK enough, Well, I don't think it's OK to essentially say: "--no-abbrev-commit" negates "--oneline" when it doesn't. Yes, I even actually checked it doesn't, just in case. > but as long as the updated text is easier to understand, > that is fine ;-) Admittedly, not being a native speaker, I'm not sure the form I used is a good English, but at least it's factually correct. Actually, I'd drop it altogether, to read like this: --no-abbrev-commit:: Show the full 40-byte hexadecimal commit object name. This negates `--abbrev-commit` as well as overrides the `log.abbrevCommit` variable. as I don't see why such clarification is at all needed in the first place. I'll re-roll if you agree this variant is better. > > Keeping the original sentence structure, e.g. > > ... and those options which imply abbreviating commit object names > such as ... > > would have been what I wrote, instead of "either explicit or implied > by", though. Sorry, but it'd then read: This negates `--abbrev-commit` and those options which imply abbreviating commit object names such as "--oneline". that again essentially reduces to: This negates "--oneline" that is simply false statement, being exactly the problem of the original that the patch tries to fix. Thanks, -- Sergey
