From: Junio C Hamano <gitster@pobox.com>
To: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com>
Cc: git@vger.kernel.org, Elijah Newren <newren@gmail.com>
Subject: Re: [GSoC][PATCH v2] merge-strategies.adoc: detail submodule merge
Date: Thu, 20 Feb 2025 11:12:50 -0800 [thread overview]
Message-ID: <xmqqmsegctvx.fsf@gitster.g> (raw)
In-Reply-To: <20250220151207.3248-1-lucasseikioshiro@gmail.com> (Lucas Seiki Oshiro's message of "Thu, 20 Feb 2025 12:12:07 -0300")
Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:
> Submodule merges are, in general, similar to other merges based on oid
> three-way-merge. When a conflict happens, however, Git has two special
> cases (introduced in 68d03e4a6e44) on handling the conflict before
> yielding it to the user. From the merge-ort and merge-recursive sources:
>
> - "Case #1: a is contained in b or vice versa": both strategies try to
> perform a fast-forward in the submodules if the commit referred by the
> conflicted submodule is descendant of another;
>
> - "Case #2: There are one or more merges that contain a and b in the
> submodule. If there is only one, then present it as a suggestion to the
> user, but leave it marked unmerged so the user needs to confirm the
> resolution."
>
> Add a small paragraph on merge-strategies.adoc describing this behavior.
>
> Helped-by: Elijah Newren <newren@gmail.com>
> Signed-off-by: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com>
> ---
>
> This v2 changes the documentation text to a clearer explanation (as
> suggested in the v1 review), and changes its location to
> merge-strategies.adoc instead of git-merge.adoc.
>
> This content is duplicated as this works for both `ort` and `recursive`
> strategies.
>
> Documentation/merge-strategies.adoc | 15 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/merge-strategies.adoc b/Documentation/merge-strategies.adoc
> index 5fc54ec060..a7fca249e2 100644
> --- a/Documentation/merge-strategies.adoc
> +++ b/Documentation/merge-strategies.adoc
> @@ -21,6 +21,13 @@ ort::
> ("Ostensibly Recursive's Twin") and came from the fact that it
> was written as a replacement for the previous default
> algorithm, `recursive`.
> +
> + In the case where the path is a submodule, if the submodule commit
> + used on one side of the merge is a descendant of the submodule
> + commit used on the other side of the merge, Git attempts to
> + fast-forward to the descendant. Otherwise, Git will treat this case
> + as a conflict, suggesting as a resolution a submodule commit that
> + is descendant of the conflicting ones, if one exists.
> +
> The 'ort' strategy can take the following options:
I am not going to comment on the text, but as to the formatting, I'd
point out that the existing
+
The 'ort' strategy can ...
construct, i.e. a line with only '+' on it, followed by left-aligned
block of text, is how AsciiDoc wants our second and subsequent
paragraphs for an enumerated list of explanations. Here, the
existing "The 'ort' strategy can ..." is the second paragraph that
follows the paragraph that ends with "... previous default
algorithm, 'recursive'", which is the explanation for the item with
"ort::" heading.
So, you'd need to (1) change the empty line at the beginning of your
added text to have one '+' and nothing else on it, and (2) dedent
the rest of the text you added to abut the left edge of the page.
Ditto for the other hunk on "recursive::".
Thanks.
next prev parent reply other threads:[~2025-02-20 19:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-20 15:12 [GSoC][PATCH v2] merge-strategies.adoc: detail submodule merge Lucas Seiki Oshiro
2025-02-20 18:46 ` D. Ben Knoble
2025-02-20 19:12 ` Junio C Hamano [this message]
2025-02-21 10:17 ` Jean-Noël Avila
2025-02-21 18:07 ` Junio C Hamano
2025-02-22 19:36 ` Lucas Seiki Oshiro
2025-02-22 22:17 ` Junio C Hamano
2025-02-24 17:31 ` D. Ben Knoble
2025-02-21 21:56 ` Elijah Newren
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=xmqqmsegctvx.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=lucasseikioshiro@gmail.com \
--cc=newren@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).