Wie füge ich einen Zweig mit Git zusammen, indem ich die Geduldsoption verwende, die von der rekursiven Strategie bereitgestellt wird? Ich verwende die Git-Version 1.7.3.1.msysgit.0
Auch Dokumente sind nicht konsistent und unterscheiden sich darüber hinaus von den tatsächlichen Befehlsausgaben.
Docs sagen:
git zusammenführen [-s <strategy>] [-X <strategy-option>] <commit>
und weiter im Text:
-X<option>
(kein Platz)
Die Ausgabe des Befehls sagt:
-X, --strategy-option <option=value>
option for selected merge strategy
Also habe ich ein paar Versionen mit folgenden Ergebnissen ausprobiert:
$ git merge -s recursive -Xpatience sourceBranch
fatal: Unknown option for merge-recursive: -Xpatience
$ git merge -X patience sourceBranch
fatal: Unknown option for merge-recursive: -Xpatience
$ git merge -Xpatience sourceBranch
fatal: Unknown option for merge-recursive: -Xpatience
$ git merge --strategy-option patience sourceBranch
fatal: Unknown option for merge-recursive: -Xpatience
$ git merge -X option=patience sourceBranch
fatal: Unknown option for merge-recursive: -Xoption=patience
$ git merge --strategy-option option=patience sourceBranch
fatal: Unknown option for merge-recursive: -Xoption=patience
$ git merge option=patience sourceBranch
fatal: 'option=patience' does not point to a commit
$ git merge -X option=patience sourceBranch
fatal: Unknown option for merge-recursive: -Xoption=patience
Anscheinend ist die Option nicht implementiert…
Das --patience Option für git merge-recursive wurde in Commit eingeführt 58a1ece478c6038a7eb0b6e494d563bd5e6d5978. Sie können es in einem Klon von herausfinden git.git welche Versionen enthalten diese Änderung mit git tag --contains 58a1ece478:
v1.7.4
v1.7.4-rc0
v1.7.4-rc1
v1.7.4-rc2
v1.7.4-rc3
v1.7.4.1
Ich vermute also, dass Sie nur eine etwas zu alte Version von mSysGit verwenden. Es ist jetzt eine Vorschauversion von 1.7.4 verfügbar – ich denke, Sie sollten diese ausprobieren.
Ich habe dies gerade mit Git-Version 1.7.4 versucht, und die folgende Befehlszeilensyntax funktioniert für mich:
git merge -s recursive -X patience other-branch
Update Aug. 2021, 10 Jahre später: kein “rekursives Zusammenführen” mehr:
Mit Git 2.34 (Q4 2021) wird die Ursprünglich Zusammenführungsstrategie wird zu ORT (“Ostensibly Recursive’s Twin”)
Sehen Commit 81483fe, 67feccd begehen, Commit 6320813, begehen Sie b36ade2, begehen 4d15c85, begehen 002a6df, Commit 510415e, e80178e übergeben, b378df7 übergeben, e037c2e übergeben (04.08.2021) von Elijah Newren (newren).
(Zusammengeführt von Junio C. Hamano — gitster — in aca13c2 übergeben30.08.2021)
81483fe613:Fehlermeldung und Codekommentar aktualisieren
Bestätigt von: Derrick Stolee
Bestätigt von: Johannes Schindelin
Unterzeichnet von: Elijah Newren
Es gab zwei Stellen im Code, die sich auf „merge-recursive“ bezogen, die aber auch auf „merge-ort“ anwendbar waren.
Aktualisieren Sie sie auf allgemeinere Formulierungen.
Mit Git 2.34 (Q4 2021), Dokumentationsaktualisierungen.
Sehen Commit 81483fe, 67feccd begehen, Commit 6320813, begehen Sie b36ade2, begehen 4d15c85, begehen 002a6df, Commit 510415e, e80178e übergeben, b378df7 übergeben, e037c2e übergeben (04.08.2021) von Elijah Newren (newren).
(Zusammengeführt von Junio C. Hamano — gitster — in aca13c2 übergeben30.08.2021)
merge-strategies schließt jetzt in seine ein Manpage:
ort
Dies ist als Drop-in-Ersatz für die gedacht recursive
Algorithmus (wie in seinem Akronym „Ostensibly Recursive’s Twin“ zum Ausdruck kommt) und wird ihn wahrscheinlich in Zukunft ersetzen.
Es behebt Eckfälle, die die recursive Die Strategie funktioniert suboptimal und ist in großen Repositories erheblich schneller – insbesondere wenn viele Umbenennungen erforderlich sind.
Das ort Strategie nimmt alle die gleichen Optionen wie recursive.
Drei dieser Optionen werden jedoch ignoriert: no-renames,
patience und diff-algorithm.
Es läuft immer mit Umbenennungserkennung (es geht viel schneller als recursive tut) und es speziell verwendet diff-algorithm=histogram.
Und:
Verwenden Sie mit Git 2.34 (Q4 2021). ort Anstatt von recursive als Standard-Zusammenführungsstrategie.
Sehen Bestätigen Sie f5a3c5e, Commit 6a5fb96 (04.08.2021) von Elijah Newren (newren).
(Zusammengeführt von Junio C. Hamano — gitster — in begehen 8778fa830.08.2021)
f5a3c5e637:Dokumente für die Änderung des standardmäßigen Zusammenführungs-Backends aktualisieren
Unterzeichnet von: Elijah Newren
Machen Sie sich das klar ort ist die Standard-Merge-Strategie jetzt eher als recursiveeinschließlich Umzug ort an den Anfang der Liste der Merge-Strategien.
git rebase schließt jetzt in seine ein Manpage:
spezifizierten, -s ort. Beachten Sie die Umkehrung von „unser“ und
git rebase schließt jetzt in seine ein Manpage:
Standardmäßig ist die merge Befehl verwendet die ort Zusammenführungsstrategie für regelmäßige Zusammenführungen und octopus für Octopus-Merges.
Man kann eine Standardstrategie für alle Zusammenführungen festlegen, indem man die verwendet --strategy -Argument beim Aufrufen von rebase oder kann bestimmte Zusammenführungen in der interaktiven Befehlsliste überschreiben, indem ein verwendet wird exec Befehl zu rufen git merge
explizit mit a --strategy Streit.
Beachten Sie das beim Anrufen git merge ausdrücklich so, können Sie sich die Tatsache zunutze machen, dass die Labels Worktree-lokale Refs sind (die ref refs/rewritten/onto würde dem Etikett entsprechen ontozum Beispiel), um auf die Zweige zu verweisen, die Sie zusammenführen möchten.
gitfaq schließt jetzt in seine ein Manpage:
Wenn Git eine Zusammenführung durchführt, verwendet es standardmäßig eine Strategie namens the ort
merge-strategies schließt jetzt in seine ein Manpage:
ort
Dies ist die standardmäßige Zusammenführungsstrategie beim Ziehen oder Zusammenführen eines Zweigs.
Diese Strategie kann nur zwei Köpfe unter Verwendung eines 3-Wege-Merge-Algorithmus auflösen.
Wenn es mehr als einen gemeinsamen Vorfahren gibt, der für die 3-Wege-Zusammenführung verwendet werden kann, wird ein zusammengeführter Baum der gemeinsamen Vorfahren erstellt und dieser als Referenzbaum für die 3-Wege-Zusammenführung verwendet.
Es wurde berichtet, dass dies zu weniger Zusammenführungskonflikten führt, ohne Fehlzusammenführungen zu verursachen, wie anhand von Tests durchgeführt wurde, die mit tatsächlichen Zusammenführungs-Commits aus der Linux 2.6-Kernel-Entwicklungsgeschichte durchgeführt wurden.
Darüber hinaus kann diese Strategie Zusammenführungen mit Umbenennungen erkennen und handhaben.
Es verwendet keine erkannten Kopien.
Der Name für diesen Algorithmus ist ein Akronym (“Ostensibly Recursive’s Twin”) und kam von der Tatsache, dass er als Ersatz für den vorherigen Standardalgorithmus geschrieben wurde. recursive.
merge-strategies schließt jetzt in seine ein Manpage:
Die ‘Ort’-Strategie kann die folgenden Optionen annehmen:
recursive
Dies kann nur zwei Köpfe unter Verwendung eines 3-Wege-Merge-Algorithmus auflösen.
Wenn es mehr als einen gemeinsamen Vorfahren gibt, der für die 3-Wege-Zusammenführung verwendet werden kann, wird ein zusammengeführter Baum der gemeinsamen Vorfahren erstellt und dieser als Referenzbaum für die 3-Wege-Zusammenführung verwendet.
Es wurde berichtet, dass dies zu weniger Zusammenführungskonflikten führt, ohne Fehlzusammenführungen zu verursachen, wie anhand von Tests durchgeführt wurde, die mit tatsächlichen Zusammenführungs-Commits aus der Linux 2.6-Kernel-Entwicklungsgeschichte durchgeführt wurden.
Darüber hinaus kann dies Zusammenführungen mit Umbenennungen erkennen und verarbeiten.
Es verwendet keine erkannten Kopien. Dies war die Standardstrategie zum Auflösen von zwei Köpfen von Git v0.99.9k bis v2.33.0.
Die ‘rekursive’ Strategie verwendet die gleichen Optionen wie ‘ort’.
Es gibt jedoch drei zusätzliche Optionen, die von ‘ort’ ignoriert werden (oben nicht dokumentiert), die bei der ‘rekursiven’ Strategie möglicherweise nützlich sind:
Geduld;;
Veraltetes Synonym für diff-algorithm=patience.
keine Umbenennungen;;
Deaktivieren Sie die Umbenennungserkennung. Dies überschreibt die merge.renames
Konfigurationsvariable.
Ursprüngliche Antwort (2011)
ich siehe hier den Patch Einführung der Geduldsoption in die rekursive Zusammenführungsstrategie, basierend auf Git1.7.2.2, aber ich sehe sie in keiner der nachfolgenden Versionshinweise.
Der Geduld-Diff-Algorithmus wurde jedoch seit 2009 vorgestellt und ist es auch hier detailliert.
> grep -i patience *.c
diff.c: else if (!strcmp(arg, "--patience"))
diff.c: DIFF_XDL_SET(options, PATIENCE_DIFF);
merge-recursive.c: else if (!strcmp(s, "patience"))
merge-recursive.c: o->xdl_opts |= XDF_PATIENCE_DIFF;
Der Zusammenführungsbefehl sollte diese Option verstehen … aber diese Funktion unten scheint nie aufgerufen zu werden (nirgendwo in merge-recursive.c oder in irgendeiner anderen *.c Datei!):
int parse_merge_opt(struct merge_options *o, const char *s)
{
if (!s || !*s)
return -1;
if (!strcmp(s, "ours"))
o->recursive_variant = MERGE_RECURSIVE_OURS;
else if (!strcmp(s, "theirs"))
o->recursive_variant = MERGE_RECURSIVE_THEIRS;
else if (!strcmp(s, "subtree"))
o->subtree_shift = "";
else if (!prefixcmp(s, "subtree="))
o->subtree_shift = s + strlen("subtree=");
else if (!strcmp(s, "patience"))
o->xdl_opts |= XDF_PATIENCE_DIFF;
else if (!strcmp(s, "ignore-space-change"))
o->xdl_opts |= XDF_IGNORE_WHITESPACE_CHANGE;
else if (!strcmp(s, "ignore-all-space"))
o->xdl_opts |= XDF_IGNORE_WHITESPACE;
else if (!strcmp(s, "ignore-space-at-eol"))
o->xdl_opts |= XDF_IGNORE_WHITESPACE_AT_EOL;
else if (!strcmp(s, "renormalize"))
o->renormalize = 1;
else if (!strcmp(s, "no-renormalize"))
o->renormalize = 0;
else if (!prefixcmp(s, "rename-threshold=")) {
const char *score = s + strlen("rename-threshold=");
if ((o->rename_score = parse_rename_score(&score)) == -1 || *score != 0)
return -1;
}
else
return -1;
return 0;
}
Die Fehlermeldung “Unbekannte Option” wird nur von der gedruckt handle_options Funktion ein git.c.
Und XDF_PATIENCE_DIFF wird nirgendwo anders in Git-Quellen (1.7.4) angezeigt … also ja, ich weiß nicht, wie dies für die Zusammenführung implementiert werden könnte.
