{"thread":{"id":"63000","subject":"[GSoC][PATCH v3] merge-strategies.adoc: detail submodule merge","startedAt":"2025-02-25T16:19:35Z","lastAt":"2025-02-26T22:10:07Z","messageCount":3,"participants":["Lucas Seiki Oshiro","Junio C Hamano"],"isPatch":true,"patchVersion":3,"patchTotal":null},"messages":[{"id":"513025","messageId":"20250225161800.8268-1-lucasseikioshiro@gmail.com","threadId":"63000","inReplyTo":null,"subject":"[GSoC][PATCH v3] merge-strategies.adoc: detail submodule merge","fromName":"Lucas Seiki Oshiro","fromEmail":"lucasseikioshiro@gmail.com","sentAt":"2025-02-25T16:18:00Z","receivedAt":"2025-02-25T16:19:35Z","isPatch":true,"sender":{"key":"lucasseikioshiro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12701580?v=4"},"body":"Submodule merges are, in general, similar to other merges based on oid\nthree-way-merge. When a conflict happens, however, Git has two special\ncases (introduced in 68d03e4a6e44) on handling the conflict before\nyielding it to the user. From the merge-ort and merge-recursive sources:\n\n- \"Case #1: a is contained in b or vice versa\": both strategies try to\nperform a fast-forward in the submodules if the commit referred by the\nconflicted submodule is descendant of another;\n\n- \"Case #2: There are one or more merges that contain a and b in the\nsubmodule. If there is only one, then present it as a suggestion to the\nuser, but leave it marked unmerged so the user needs to confirm the\nresolution.\"\n\nAdd a small paragraph on merge-strategies.adoc describing this behavior.\n\nHelped-by: Junio C Hamano \nHelped-by: Elijah Newren \nSigned-off-by: Lucas Seiki Oshiro \n---\n\nThis v3 keeps the same content as the previous v2. However, it uses the\nproper way to declare paragraphs inside explanations and replaces the\nduplicated paragraph in `recursive` strategy by a small paragraph\ntelling that it behaves the same way as `ort` when merging submodules.\n\n Documentation/merge-strategies.adoc | 11 +++++++++++\n 1 file changed, 11 insertions(+)\n\ndiff --git a/Documentation/merge-strategies.adoc b/Documentation/merge-strategies.adoc\nindex 5fc54ec060..9c30f1c900 100644\n--- a/Documentation/merge-strategies.adoc\n+++ b/Documentation/merge-strategies.adoc\n@@ -22,6 +22,13 @@ ort::\n \twas written as a replacement for the previous default\n \talgorithm, `recursive`.\n +\n+In the case where the path is a submodule, if the submodule commit used on\n+one side of the merge is a descendant of the submodule commit used on the\n+other side of the merge, Git attempts to fast-forward to the\n+descendant. Otherwise, Git will treat this case as a conflict, suggesting\n+as a resolution a submodule commit that is descendant of the conflicting\n+ones, if one exists.\n++\n The 'ort' strategy can take the following options:\n \n ours;;\n@@ -95,6 +102,10 @@ recursive::\n \trenames. It does not make use of detected copies. This was\n \tthe default strategy for resolving two heads from Git v0.99.9k\n \tuntil v2.33.0.\n+\n++\n+For a path that is a submodule, the same caution as 'ort' applies to this\n+strategy.\n +\n The 'recursive' strategy takes the same options as 'ort'. However,\n there are three additional options that 'ort' ignores (not documented\n-- \n2.39.5 (Apple Git-154)\n\n"},{"id":"513033","messageId":"xmqqr03lkhwl.fsf@gitster.g","threadId":"63000","inReplyTo":"20250225161800.8268-1-lucasseikioshiro@gmail.com","subject":"Re: [GSoC][PATCH v3] merge-strategies.adoc: detail submodule merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-02-25T18:18:02Z","receivedAt":"2025-02-25T18:18:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lucas Seiki Oshiro writes:\n\n> Submodule merges are, in general, similar to other merges based on oid\n> three-way-merge. When a conflict happens, however, Git has two special\n> cases (introduced in 68d03e4a6e44) on handling the conflict before\n> yielding it to the user. From the merge-ort and merge-recursive sources:\n>\n> - \"Case #1: a is contained in b or vice versa\": both strategies try to\n> perform a fast-forward in the submodules if the commit referred by the\n> conflicted submodule is descendant of another;\n>\n> - \"Case #2: There are one or more merges that contain a and b in the\n> submodule. If there is only one, then present it as a suggestion to the\n> user, but leave it marked unmerged so the user needs to confirm the\n> resolution.\"\n>\n> Add a small paragraph on merge-strategies.adoc describing this behavior.\n>\n> Helped-by: Junio C Hamano \n> Helped-by: Elijah Newren \n> Signed-off-by: Lucas Seiki Oshiro \n> ---\n>\n> This v3 keeps the same content as the previous v2. However, it uses the\n> proper way to declare paragraphs inside explanations and replaces the\n> duplicated paragraph in `recursive` strategy by a small paragraph\n> telling that it behaves the same way as `ort` when merging submodules.\n>\n> Documentation/merge-strategies.adoc | 11 +++++++++++\n> 1 file changed, 11 insertions(+)\n>\n> diff --git a/Documentation/merge-strategies.adoc b/Documentation/merge-strategies.adoc\n> index 5fc54ec060..9c30f1c900 100644\n> --- a/Documentation/merge-strategies.adoc\n> +++ b/Documentation/merge-strategies.adoc\n> @@ -22,6 +22,13 @@ ort::\n> \twas written as a replacement for the previous default\n> \talgorithm, `recursive`.\n> +\n> +In the case where the path is a submodule, if the submodule commit used on\n> +one side of the merge is a descendant of the submodule commit used on the\n> +other side of the merge, Git attempts to fast-forward to the\n> +descendant. Otherwise, Git will treat this case as a conflict, suggesting\n> +as a resolution a submodule commit that is descendant of the conflicting\n> +ones, if one exists.\n> ++\n> The 'ort' strategy can take the following options:\n\nOK.\n\n> @@ -95,6 +102,10 @@ recursive::\n> \trenames. It does not make use of detected copies. This was\n> \tthe default strategy for resolving two heads from Git v0.99.9k\n> \tuntil v2.33.0.\n> +\n> ++\n> +For a path that is a submodule, the same caution as 'ort' applies to this\n> +strategy.\n> +\n> The 'recursive' strategy takes the same options as 'ort'. However,\n> there are three additional options that 'ort' ignores (not documented\n\n\nShould the blank line be added above '+'? I somehow doubt it.\n\nOther than that, looking very good.\n\nThanks.\n"},{"id":"513122","messageId":"FD1CBE9F-918A-4056-89D2-832CD07CC73C@gmail.com","threadId":"63000","inReplyTo":"xmqqr03lkhwl.fsf@gitster.g","subject":"Re: [GSoC][PATCH v3] merge-strategies.adoc: detail submodule merge","fromName":"Lucas Seiki Oshiro","fromEmail":"lucasseikioshiro@gmail.com","sentAt":"2025-02-26T22:09:53Z","receivedAt":"2025-02-26T22:10:07Z","isPatch":true,"sender":{"key":"lucasseikioshiro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12701580?v=4"},"body":"\n> Should the blank line be added above '+'? I somehow doubt it.\n\nTo be honest, this is my first time using asciidoctor, I \nsincerely don't know. Building a local pdf with\n`asciidoctor-pdf` didn't change the generated PDF. But of \ncourse, this doesn't follow the style of the rest of the\ndocument. I'm sorry, I'll fix it in v4.\n\n> Other than that, looking very good.\n\nThanks for your help in this patch!\n\n"}]}