René Scharfe <l.s.r@xxxxxx> writes: >> +It is possible that a merge failure will prevent this process from being >> +completely automatic. "`git merge --continue`" and "`git merge --abort`" > ^^^^^^^^^ > automatically > >> +can only be run after the merge has resulted in conflicts. > > The connection between these two sentences feels weak to me. Are "merge > failure" and "conflicts" the same? Perhaps something like this: > > A merge stops if there's a conflict that cannot be resolved > automatically. At that point you can run `git merge --abort` or > `git merge --continue`. Just being nitpicky and curious, but does the abort/continue also apply when you run "git merge --no-commit"? I do not do documentation all that much these days, but when I was involved heavily in discussions on documentation patches, I often said "'git merge' gives back control to the user" to refer to both cases, either because it couldn't complete the work it was asked to do, or because it was asked to stop before completing the work. > 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.
