"Elijah Newren via GitGitGadget" [off-list ref] writes:
From: Elijah Newren <redacted>
The resolve merge strategy was given prominent positioning in this
document, being listed first since it was the default at the time the
document was written. It hasn't been the default since before Git v1.0
was released, though. Move it later in the document, near `octopus` and
`ours`.
I think it was listed first because it was written first.
Further, the wording for "resolve" claimed that it was "considered
generally safe and fast", which implies that the other strategies are
not.
I do not think it never implied any such thing; it is good to remove
it, or add the same to all strategies, though.
quoted hunk
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 5d707e952aa..6b6017e1cc8 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -6,13 +6,6 @@ backend 'merge strategies' to be chosen with `-s` option. Some strategies
can also take their own options, which can be passed by giving `-X<option>`
arguments to `git merge` and/or `git pull`.
-resolve::
- This can only resolve two heads (i.e. the current branch
- and another branch you pulled from) using a 3-way merge
- algorithm. It tries to carefully detect criss-cross
- merge ambiguities and is considered generally safe and
- fast.
-
recursive::
This can only resolve two heads using a 3-way merge
algorithm. When there is more than one common
@@ -106,6 +99,13 @@ subtree[=<path>];;
is prefixed (or stripped from the beginning) to make the shape of
two trees to match.
+resolve::
+ This can only resolve two heads (i.e. the current branch
+ and another branch you pulled from) using a 3-way merge
+ algorithm. It tries to carefully detect criss-cross
+ merge ambiguities. It cannot handle renames. This was
+ the default merge algorithm prior to November 2005.
"It does not handle renames"; it wasn't like we wanted to do so and
cannot---we didn't want to, didn't think it was worth doing, it was
not part of the design objective to do renames, period.
I do not think it is even worth mentioning that it was the default
in the past. And I do not think it is worth saying what timeframe
the recursive was the default, either.
octopus::
This resolves cases with more than two heads, but refuses to do
a complex merge that needs manual resolution. It is
On Tue, Aug 3, 2021 at 6:19 PM Junio C Hamano [off-list ref] wrote:
"Elijah Newren via GitGitGadget" [off-list ref] writes:
quoted
From: Elijah Newren <redacted>
The resolve merge strategy was given prominent positioning in this
document, being listed first since it was the default at the time the
document was written. It hasn't been the default since before Git v1.0
was released, though. Move it later in the document, near `octopus` and
`ours`.
I think it was listed first because it was written first.
Do you want it to be kept first for that reason as well? I thought it
made more sense to cover the default strategy first, but I can move it
back if you prefer historical implementation order.
quoted
Further, the wording for "resolve" claimed that it was "considered
generally safe and fast", which implies that the other strategies are
not.
I do not think it never implied any such thing; it is good to remove
it, or add the same to all strategies, though.
I am unsure if your double negatives are intentional
(not..never)...but I think you're saying it's okay to remove this
text.
quoted
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 5d707e952aa..6b6017e1cc8 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -6,13 +6,6 @@ backend 'merge strategies' to be chosen with `-s` option. Some strategies
can also take their own options, which can be passed by giving `-X<option>`
arguments to `git merge` and/or `git pull`.
-resolve::
- This can only resolve two heads (i.e. the current branch
- and another branch you pulled from) using a 3-way merge
- algorithm. It tries to carefully detect criss-cross
- merge ambiguities and is considered generally safe and
- fast.
-
recursive::
This can only resolve two heads using a 3-way merge
algorithm. When there is more than one common@@ -106,6 +99,13 @@ subtree[=<path>];;
is prefixed (or stripped from the beginning) to make the shape of
two trees to match.
+resolve::
+ This can only resolve two heads (i.e. the current branch
+ and another branch you pulled from) using a 3-way merge
+ algorithm. It tries to carefully detect criss-cross
+ merge ambiguities. It cannot handle renames. This was
+ the default merge algorithm prior to November 2005.
"It does not handle renames"; it wasn't like we wanted to do so and
cannot---we didn't want to, didn't think it was worth doing, it was
not part of the design objective to do renames, period.
Right, sorry for the poor wording. I'll fix it to use your phrase.
I do not think it is even worth mentioning that it was the default
in the past. And I do not think it is worth saying what timeframe
the recursive was the default, either.
I don't feel strongly about it and I can strike it. My reasoning was
that providing historical timeframes might help them repeat or
recreate old merges in their own repositories.
However, I agree that the more likely bits of information that will
help users select the strategy they want are the capabilities (e.g.
renames, criss-cross merges, number of heads, etc.).