Wie rebasiert man nach dem Hinzufügen von Git-Subtree?

Ich versuche, das Neue zu lernen git-Unterbaum Befehl, der in Git 1.7.11 hinzugefügt wurde. Ich scheine die Fähigkeit zum Rebase zu verlieren, nachdem ich einen Teilbaum hinzugefügt habe. Ich habe das primäre Repository mit README-Datei und ein Bibliotheks-Repository, das auch eine README-Datei enthält. Ich füge es dem lib-Verzeichnis mit hinzu subtree add:

$ git subtree add -P lib/mylib myliborigin master

Das funktioniert gut, aber jetzt sieht der Verlauf so aus:

*   22c1fe6 (HEAD, master) Merge commit 'b6e698d9f4985825efa06dfdd7bba8d2930cd40e' as 'lib/mylib' - 
|\                                                                                                                
| * b6e698d Squashed 'lib/mylib/' content from commit d7dbd3d
* b99d55b Add readme
* 020e372 Initial

Jetzt, wo ich mein Repo gegen rebasen möchte origin/master und es schlägt fehl, weil das Squash-Commit direkt auf sein übergeordnetes Commit angewendet wird, was nicht zutrifft, da es auf das Stammverzeichnis des Repos angewendet wird und nicht auf das Präfix, das ich ihm beim Hinzufügen des Unterbaums gegeben habe.

Der Grund dafür ist ziemlich klar, wenn ich mir den Squash-Commit anschaue. Es gibt keine Informationen über das Präfix. Es sind nur die ursprünglichen mylib-Commits, die zusammengedrückt wurden. Nur der nächste Merge-Commit weiß etwas davon, aber rebase berücksichtigt es hier nicht.

Gibt es Problemumgehungen (abgesehen davon, niemals über die Subtree-Commits zu rebasen)?

Das funktioniert in einfachen Fällen:

git rebase --preserve-merges master

Danke an @Techlive Zheng in den Kommentaren.

Sie können sehen

fatal: refusing to merge unrelated histories
Error redoing merge a95986e...

Was bedeutet, dass Git Ihren Teilbaum nicht automatisch anwenden konnte. Dies bringt Sie in die Situation, die @ericpeters in seiner Antwort beschrieben hat. Lösung:

Fügen Sie Ihren Teilbaum erneut hinzu (verwenden Sie denselben Befehl, den Sie ursprünglich verwendet haben):

git subtree add -P lib lib-origin master

Rebase fortsetzen:

git rebase --continue

Und du bist fertig!

Wenn Sie sich fragen, ob es erfolgreich funktioniert hat, können Sie nach dem Rebasing mit Ihrer ursprünglichen Version vergleichen, um sicherzustellen, dass Sie nichts geändert haben:

git diff <ref-before-rebase> <ref-after-rebase> -- .

(das -- . am ende weist git nur noch an diff die Dateien in Ihrem aktuellen Verzeichnis).

Wenn alles andere fehlschlägt und Sie sich nicht darum kümmern, die Commits selbst zu erhalten, können Sie einfach git cherry-pick das ursprüngliche Teilbaum-Commit.

Die Commit-Nachricht sieht in etwa so aus Add 'lib/' from commit '9767e6...' – das ist es, was du willst.

Dies ist eine alte Frage, aber ich hatte gerade das gleiche Problem mit meinem Repo und habe endlich eine vollständige Lösung gefunden, die (hoffentlich) alle Subtree-Metadaten beibehält.

Angenommen, wir hätten diesen Commit-Baum:

B   (master) Add README.md
|     
A            Initial commit

und wir gabelten a feature Zweig, in dem sich ein Teilbaum befindet lib/:

git remote add -f githublib https://github.com/lib/lib.git
git subtree add --prefix lib/ githublib master --squash

Es erstellt ein Merge-Commit D mit zwei Eltern: unserem aktuellen master (B) und einem nicht verwandten Commit F mit der gequetschten Geschichte des externen Repos. Dieser Commit enthält auch einige git subtree Metadaten in seiner Commit-Nachricht (nämlich git-subtree-dir und git-subtree-split).

   D     (feature) Merged commit 'F' as 'lib/'
  / \    
 /   F             Squashed 'lib/' content from GGGGGG
B        (master)  Add README.md
|     
A                  Initial commit

Später fügen wir beiden Zweigen unabhängig voneinander einige Commits hinzu.

   E     (feature) Remove .gitignore from lib/
C  |     (master)  Add LICENSE.md
|  D               Merged commit 'F' as 'lib/'
| / \    
|/   F             Squashed 'lib/' content from GGGGGG
B                  Add README.md
|     
A                  Initial commit

Jetzt wollen wir umrüsten feature auf zu master. Hier ist wie:

1. Wählen Sie die Commits aus feature nacheinander, um eine neue Kopie der zu erstellen feature Zweig oben auf master.

git branch -f feature C
git checkout feature
git cherry-pick D E

E'       (feature) Remove .gitignore from lib/
|
D'                 Merged commit 'F' as 'lib/'
|
|  E               Remove .gitignore from lib/
C  |     (master)  Add LICENSE.md
|  D               Merged commit 'F' as 'lib/'
| / \    
|/   F             Squashed 'lib/' content from GGGGGG
B                  Add README.md
|     
A                  Initial commit

Jetzt haben wir das Äquivalent einer Rebase, aber wir haben alle Informationen über das externe Repo verloren, die für erforderlich sind git subtree. Um es wiederherzustellen:

2. Fügen Sie den fehlenden übergeordneten Link als Graft hinzu und schreiben Sie den Verlauf von neu feature um es dauerhaft zu machen.

git checkout feature
git replace --graft D' C F
git filter-branch --tag-name-filter cat -- master..

Und jetzt erhalten wir ein Bild, das genau dem entspricht, mit dem wir begonnen haben. Die alten Commits D und E sind immer noch da draußen, aber sie können später aussortiert werden.

E'       (feature) Remove .gitignore from lib/
|
D'                 Merged commit 'F' as 'lib/'
|\
| \                
C  \     (master)  Add LICENSE.md
|   \              
|    \   
|     F            Squashed 'lib/' content from GGGGGG
B                  Add README.md
|     
A                  Initial commit

Warnung: Damit wird die Geschichte neu geschrieben feature, seien Sie also vorsichtig mit der Veröffentlichung, wenn jemand anderes mit Ihnen in diesem Zweig zusammenarbeitet. Da du aber in erster Linie eine Rebase machen wolltest, ist dir das wahrscheinlich bewusst 🙂

Dies ist keine Lösung, aber es ist die aktuelle Arbeit, die ich verwende …

Anhand Ihres Ausgangsbeispiels:

*   22c1fe6 (HEAD, master) Merge commit 'b6e698d9f4985825efa06dfdd7bba8d2930cd40e' as 'lib/mylib' - 
|\                                                                                                                
| * b6e698d Squashed 'lib/mylib/' content from commit d7dbd3d
* b99d55b Add readme
* 020e372 Initial

Rebasieren Sie interaktiv auf den 2. Commit, bevor Sie den Teilbaum hinzufügen:

$ git rebase -i 020e372

Löschen Sie die beiden Unterbaumeinträge und markieren Sie die Bearbeitung für den vorherigen Commit:

e b99d55b Add readme

Datei speichern/schließen, dann, wenn es zum Commit „Readme hinzufügen“ kommt, den Änderungsbefehl ausführen:

$ git commit --amend

Fügen Sie dann Ihren neuen Teilbaum erneut hinzu:

$ git subtree add -P lib/mylib myliborigin master

Rebase fortsetzen:

$ git rebase --continue

Ihr Zweig sollte dann vom Master umbasiert werden, und der Teilbaum wird “normal” sein, wobei Squash + the Merge intakt sind:

*   22c1fe6 (HEAD, master) Merge commit 'b6e698d9f4985825efa06dfdd7bba8d2930cd40e' as 'lib/mylib' - 
|\                                                                                                                
| * b6e698d Squashed 'lib/mylib/' content from commit d7dbd3d

Git 2.24.0 (veröffentlicht am 04.11.2019) hat Unterstützung für hinzugefügt git rebase --rebase-merges --strategy [strategy]. Also wenn du jetzt rennst git rebase --rebase-merges --strategy subtree [branch] Wenn Ihr aktueller Zweig eine Teilbaumzusammenführung enthält, funktioniert es jetzt einfach.

Für mein Projekt habe ich beschlossen, dass ich es möglicherweise nicht verwende git subtree addsondern werfen Sie stattdessen den zweiten Elternteil des Merge-Commits mit weg git replace --edit. habe ich auch benutzt das veraltete „subtree“-Tutorial des Git-Buchs v1was dasselbe tut, aber langweilig ist.

Anscheinend ist dies erwartetes Verhalten (für eine perverse Definition von “erwartetes Verhalten”). Siehe: http://git.661346.n2.nabble.com/subtree-merges-lose-prefix-after-rebase-td7332850.html.

Nicht, dass dies für irgendjemanden eine große Hilfe wäre. Ich würde auch gerne einen Workaround dafür finden.

Ich hatte ein ähnliches Problem: Ich wollte nach dem Hinzufügen eines Unterbaums eine neue Basis erstellen, und die Verwendung von –preserve-merges hinterließ immer noch einen Zusammenführungskonflikt (aufgrund von Konflikten .gitignore Dateien und andere).

In meinem Fall hatte ich nicht unbedingt vor, eine Teilbaumfunktionalität zu verwenden: Ich habe einfach ein Repo eingefügt, das ursprünglich Teil des Superprojekts hätte sein sollen. Falls es jemand anderem hilft, habe ich Folgendes getan, basierend auf anderen verwandten Antworten, die ich gefunden habe.

Angenommen, ich habe zwei Projekte, main_project und sub_project, im selben Verzeichnis. Ich möchte sub_project in ein Verzeichnis namens sub_project innerhalb von main_project ziehen, vorausgesetzt, dass keines der Repos jemals ein Verzeichnis namens sub_project hatte:

cd main_project
git fetch ../sub_project
git checkout -b sub_project FETCH_HEAD
git filter-branch --prune-empty --tree-filter '
    if [[ ! -e sub_project ]]; then
        mkdir -p sub_project
        git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files sub_project
    fi'
git checkout branch-to-merge-within
git merge sub_project
git branch -d sub_project

Ich werde aktualisieren, wenn ich Probleme mit diesem Ansatz finde.

Sie müssen verwenden

git rebase --preserve-merges --preserve-committer --onto new_place start end