2016-05-17 9 views
19

Ich habe drei repos - Namen für Klarheit geändert:Merging subtree Änderungen - fatal: ungültiger Pfad 'somefile_BASE_20704.cs'

SharedStuff, ProjectA und ProjectB

Beide Projekte werden mit git-Unterstruktur zu halten eine lokale Kopie von . Beide haben lokale Änderungen vorgenommen, die ich zentral zusammenführen, testen und dann wieder zusammenführen möchte.

Ich habe dies auf der ProjectA Repo laufen:

git subtree split --prefix=SharedStuff -b SharedStuff_from_ProjectA --rejoin

... schob dann, dass zum SharedStuff Repo, ein paar einfachen Konflikte gelöst, fusionierte sie nach oben.

Jetzt habe ich diese auf dem ProjectB Repo laufen:

git subtree split --prefix=platform/SharedStuff -b SharedStuff_from_Project_B --rejoin

... und schob wieder, dass auf die SharedStuff Repo in einem neuen Zweig. . Das Problem tritt auf, wenn ich versuche, in jene Änderungen zu verschmelzen

Im aktuellen Fall, wechsle ich auf die SharedStuff_from_Project_B Zweig, dann git merge master - aber ich sofort alle geänderten Dateien als add aufgeführt erhalten/ Konflikte hinzufügen. Als ich git mergetool laufen, hat jeder einen Fehler wie folgt aus:

Merging: 
somefile.xyz 

Normal merge conflict for 'somefile.xyz': 
    {local}: created file 
    {remote}: created file 
fatal: invalid path './somefile.xyz_BASE_20704.cs' 

(Natürlich, wenn ich die andere Art und Weise versuchen, um - SharedStuff_from_Project_B in master zu verschmelzen - bekomme ich die gleichen Arten von Konflikten, umgekehrt nur noch. hinzufügen/hinzufügen).

Meine Vermutung ist, dass etwas in der Geschichte von ProjectB falsch sein könnte, was das Erscheinen von Add/Adds verursacht. Ich bin mir nicht sicher, wie ich das weiter diagnostizieren soll - was kann ich tun?

bearbeiten: es gab einen vorherigen Teilbaum „wieder zusammenzubringen“ begehen in ProjectB, aber die Änderungen wurden nicht verschmolzen zu SharedStuff an diesem Punkt scheint es. Aber das erneute Ausführen von git subtree split mit --ignore-joins erzeugt das gleiche Problem - viele add/add Zusammenführungskonflikte, trotz der Geschichte dieser geteilten Unterbaum Verzweigung geht zurück, wenn die SharedStuff wurde erstmals in ProjectB gelegt. :(

bearbeiten: Auch git merge-base zwischen der geteilten Teilstruktur von ProjectB und master auf SharedStuff gibt keine Ergebnisse Ich bin nicht sicher, wie dies kam zu sein oder, wie zu lösen

+0

Hier gehen wir, Kopfgeld # 3 ... –

Antwort

1

ich.? . weiß nicht, was dies verursacht aber hier ist, wie ich es gelöst -.! Art habe ich noch eine bessere Antworten wollen

Beide ‚shared‘ Zweige der tatsächliche Haupt auf SharedStuff und die abgespaltene Kopie von ProjectB hatte die gleiche begeht in ihrer fernen Geschichte - nun, die gleichen Änderungen mit dem gleichen tree SHAs intern, aber unterschiedliche SHAs. Dies liegt daran, dass der Zweig ProjectB irgendwie einen anderen ersten Commit hatte als SharedStuff.

Solange es keine gemeinsamen Commits (mit den gleichen SHAs) in der History gab, werden Merging, Rebasing usw. keine gemeinsame Grundlage finden und annehmen, dass Dateien in beiden Historien hinzugefügt wurden.

Die Lösung: Finden Sie zwei begeht früh in der Geschichte mit dem gleichen tree SHA (dh genau dem gleichen Dateiinhalt), und verpflichtet Info - Nachricht, Autor usw. - und manuell ‚überschreiben‘ die Eltern davon begehen in ProjectB ' s split Zweig in den Eltern in SharedStuff Master.

Ich tat dies ein Transplantat mit: Setting git parent pointer to a different parent

  1. Schreiben Sie eine neue Linie zu .git/info/grafts, im Grunde wrong-parent right-parent
  2. Wechseln Sie in den Zweig - entdecken Powershell echo ein 16-Bit-Zeichenformat verwendet wird, erneut speichern mit Sublime Text und wieder einschalten;)
  3. Run git filter-branch right-parent..HEAD auf dem Zweig zu versiegeln, das Geschäft
  4. alles Überprüfen zusammenführbar

Die nächste lustige Herausforderung wird sein, zu sehen, wie diese Version wieder in ProjectB integriert wird; wird aktualisiert, wenn das fertig ist ..

Ich würde immer noch eine echte Antwort wirklich begrüßen - das ist wirklich hacky!

+0

Schnelle Korrektur: die Graft-Linie sollte eigentlich "Kind-von-falsch-Eltern-rechts-Elternteil" sein. Aber ich möchte immer noch nicht darauf zurückgreifen. –