Hey! Thank you all for your great reviews! > Thank you for this patch and sorry for the nitpicking below! No need to be sorry - this is what I am here for since it is the only way to learn ;-) (also I am not a native speaker, so I know I am constantly making mistakes) > "Synopsys" is a software company. A "synopsis" is a brief outline. Oh yeah... Now I need a face-palm emoji :D This is what you get from trusting the spell check for words you just tried to copy far too early in the morning... And another thing to learn for me: don't submit patches while you are not yet fully awake... Sorry for everyone who had to read the first draft! That was indeed not very professional from me... > Had to think a moment before I understood that "enumeration" refers to > "The second syntax" and "The third syntax", which have been combined > into this line: > > git merge (--continue | --abort | --quit) > > And it does make sense that we can no longer say "second syntax" and > only refer to "git merge --abort", or "third syntax" and mean "git > merge --continue". In other words: References by number are no longer > valid after a merge of some of the synopses. That sums it up a lot better. I wasn't happy with my first draft, but couldn't come up with something better - now I used your explanation with a slight variation. > > The connection between these two sentences feels weak to me. > > This sentence is a bit more problematic than that: Even when there are > no conflicts, "git merge --no-commit" will also stop a merge, and one > can then use either --abort or --continue. So the assertion made by > this sentence that you're reviewing is not accurate. Oh! Another thing I learned today! Thanks a lot for pointing that out! I have to confess: I copied that sentence 1:1 from git-rebase - that is also why it did not fit in with the next sentence... But Renés suggestion just avoids this (and the "--continue") problem altogether, so I went with a slight variation of it instead. > I like this alternative wording Same! I fumbled around with it just a bit to include your hint > Possibly. This looks like a case of me making a mistake while > criticizing someone else's grammar, though. Which happens almost > every time. o_O We all make mistakes (and my own grammar is horrific...), but the more I appreciate it when people suggest/ask things because that always gives me the opportunity to learn as well. And you are totally right in that this sentence does not "feel quite right" anyways, so I understand your unease with it and why you wanted to discuss it ;-) > Just being nitpicky and curious, but does the abort/continue also > apply when you run "git merge --no-commit"? Yes, indeed that seems to be the case (also pointed out simultaneously by Elijah Newren). I extended Renés suggestion to mention it as well. > > The only guidance I found is this paragraph from CodingGuidelines: > > > > Literal examples (e.g. use of command-line options, command names, > > branch names, URLs, pathnames (files and directories), configuration and > > environment variables) must be typeset in monospace (i.e. wrapped with > > backticks) > > > > So shouldn't we wrap all commands in backticks and nothing more? > > Probably worth a separate patch. > > Thanks for a good review. Indeed! That was very nice! And I also added the suggested changes as a second patch. It applies just fine to master without the first one, though that obviously would leave the changed paragraphs from the first commit with the mixed syntax, but that would just be a minor inconsistency until the first patch (or a future version of it) is applied. Cheers Michael Michael Lohmann (2): Documentation/git-merge.txt: fix reference to synopsis Documentation/git-merge.txt: use backticks for command wrapping Documentation/git-merge.txt | 70 ++++++++++++++++++------------------- 1 file changed, 35 insertions(+), 35 deletions(-) -- 2.39.3 (Apple Git-145)
