From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: Michael Lohmann <mial.lohmann@gmail.com>,
git@vger.kernel.org, Michael Lohmann <mi.al.lohmann@gmail.com>
Subject: Re: [PATCH] Documentation/git-merge.txt: fix reference to synopsys
Date: Wed, 20 Dec 2023 08:51:40 -0800 [thread overview]
Message-ID: <xmqq4jgcu89v.fsf@gitster.g> (raw)
In-Reply-To: <c6814a39-b4f9-4b1e-b81b-45ffe4aa7466@web.de> ("René Scharfe"'s message of "Wed, 20 Dec 2023 16:43:16 +0100")
René Scharfe <l.s.r@web.de> 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.
next prev parent reply other threads:[~2023-12-20 16:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-20 7:05 [PATCH] Documentation/git-merge.txt: fix reference to synopsys Michael Lohmann
2023-12-20 15:43 ` René Scharfe
2023-12-20 16:29 ` Elijah Newren
2023-12-20 17:18 ` René Scharfe
2023-12-20 16:51 ` Junio C Hamano [this message]
2023-12-20 19:53 ` [PATCH 0/2] Documentation/git-merge.txt: fix reference to synopsis Michael Lohmann
2023-12-20 19:53 ` [PATCH 1/2] " Michael Lohmann
2023-12-20 20:45 ` Elijah Newren
2023-12-20 20:56 ` Junio C Hamano
2023-12-20 21:35 ` [PATCH v3 " Michael Lohmann
2023-12-20 21:39 ` Junio C Hamano
2023-12-20 22:09 ` Michael Lohmann
2023-12-20 19:53 ` [PATCH 2/2] Documentation/git-merge.txt: use backticks for command wrapping Michael Lohmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq4jgcu89v.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=l.s.r@web.de \
--cc=mi.al.lohmann@gmail.com \
--cc=mial.lohmann@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).