git erkennt die Umbenennung nicht

Einem Zweig (refactoringBranch) hatte ein komplettes Verzeichnis der Umstrukturierung. Dateien verschoben wurden, chaosly, aber der Inhalt wurde beibehalten.

Ich habe versucht, zu fusionieren:
git merge --no-ff -Xrename-threshold=15 -Xpatience -Xignore-space-change refactoringBranch

git status zeigt etwa die Hälfte der Dateien umbenennen Anerkennung. Aber aus 10000 Dateien in das Projekt, die Hälfte war nicht erkannt als bewegt.

Ein Beispiel wäre:

# On branch master
# Changes to be committed:

#   deleted:    404.php
#   new file:   public_html/404.php
    ...
#   deleted:    AnotherFile.php
#   new file:   public_html/AnotherFile.php
    ...
#   renamed:    contracts/css/view.css -> public_html/contracts/css/view.css

Vorschläge?

Vorgeschichte

Die Umgestaltung vorgenommen wurde, außerhalb des git. Ich habe die folgenden:

  1. Erstellt die refactoringBranch Ursprung auf master.
  2. Sank der veränderten Struktur innerhalb der refactoringBranch, das heißt, ich hatte meine änderungen in einige andere dir einfach kopieren-einfügen, die Sie über mein git-repository.
  3. Hinzugefügt und verpflichtet alles und dann versucht zu verbinden.

Dies ist war mein workflow:

git checkout -b refactoringBranch
cp -R other/place/* ./
git add . -A
git commit -a -m "blabla"
git checkout master
git merge --no-ff -Xrename-threshold=15 -Xpatience -Xignore-space-change refactoringBranch

Das problem entstehen, auf die git add . -A Schritt wahrscheinlich.
Denn wenn umbenennen Detektion richtig war es, ich würde davon ausgehen, das mischen würde gehen einwandfrei.

Kommentar zu dem Problem - Öffnen
Ich habe mit einem externen tool, ist die ähnlichkeit zwischen 404.php in master und public_html/404.php auf refactoringBranch, erschienen auf 95.37%. Kommentarautor: Alex
Welche externen tool war das? Haben Sie getestet, verschiedene umbenennen Schwellenwerte mit so etwas wie git diff -M90% --stat master refactoringBranch (der Versuch mit verschiedenen Werten statt 90%)? Kommentarautor: John Bartholomew
Das Werkzeug wurde in php.net/similar_text. In meiner merge-Befehl, den ich bin mit Schwelle so niedrig wie 15 Prozent. Ich würde erwarten, dass es zu übergeben. Kommentarautor: Alex
Dieser workflow schlägt vor, dass der Meister wird auch der merge-base. Ist das richtig? Kommentarautor: John Bartholomew
lassen Sie uns weiter, diese Diskussion im chat Kommentarautor: John Bartholomew

InformationsquelleAutor der Frage Alex | 2012-12-10

  1. 24

    Umbenennen-Erkennung:

    Meine beste Vermutung ist, dass umbenennen Erkennung ist nicht wegen der sehr großen Zahl von Kandidaten. Der git source code ist ein wenig schwer zu Folgen, an Orten, aber es scheint, dass es einige hart-codiert Grenzen insbesondere Suche Schritte von der rename-detection-Algorithmus (siehe diffcore-umbenennen.c), sowie die konfigurierbares limit für die maximale Anzahl von Paaren zu sehen (Konfiguration, Schlüssel diff.renameLimit und merge.renameLimit). Diese können die Erkennung fehlschlagen, selbst wenn Sie festgelegt haben, dass das konfigurierte limit entsprechend hoch ist. Das konfigurierbare limit selbst ist gespannt auf den Bereich [1, 32767].

    Vielleicht können Sie dies umgehen, indem Sie eine Umstrukturierung ersten Schritt: verschieben von Dateien mit git mv ohne irgendwelche inhaltlichen änderungen, entsprechend dem neuen layout, commit, auf eine neue Filiale, und dann ersetzen Sie es mit Ihrem endgültige version, die Sie haben sollten, nur der Inhalt ändert und nicht benennt. Benennt keine inhaltlichen änderungen könnte erkannt werden mehr zuverlässig. Das ist nur dann sinnvoll, wenn die Umstrukturierung, die Sie getan haben, war ziemlich einfach, und ich bin nicht sicher, dass es zu lösen, wird der umbenennen-Erkennung Fehler.

    Alternativ vielleicht können Sie teilen Sie die änderungen in separate commits mit einigen einfachen Datei-Gruppierungen, so dass es weniger Kandidaten für das umbenennen Erkennung in den einzelnen verpflichten.

    Zusammenführen:

    Leider, auf der Grundlage der neuen Filiale an der Spitze von master -, Sie geben falsche Informationen über git den merge. Unabhängig davon, ob die benennt sind richtig erkannt oder nicht, wenn die neu erstellte Zweig zusammengeführt wird mit der master-es überschreibt alles, was im master, da von git Sicht keine änderungen gibt es in master, die nicht bereits in der neuen Filiale.

    InformationsquelleAutor der Antwort John Bartholomew

  2. 29

    OS X ist der Fall-bewusst, aber nicht empfindlich. Git ist groß-und Kleinschreibung. Wenn Sie eine Datei geändert name und die einzige änderung war ein Fall ändern, benennen Sie die Datei zurück zu der Weise war es, dann verwenden Sie git mv umbenennen statt.

    InformationsquelleAutor der Antwort andrhamm

  3. 27

    Statt git status versuchen git commit --dry-run -a es erkennt, benennt besser.

    InformationsquelleAutor der Antwort BoD

  4. 0

    Könntest du überlegen, mit git mv statt: https://www.kernel.org/pub/software/scm/git/docs/git-mv.html

    Es wurde sehr viel sicherer in meiner Erfahrung.

    InformationsquelleAutor der Antwort sungiant

  5. -3

    Immer wenn ich umbenennen/verschieben von Dateien und vergessen zu sagen, GIT explizit darüber ich verwendet

    git add . -A

    die automatische Erkennung von Dateien, die verschoben wurden, um

    InformationsquelleAutor der Antwort Sergey Lukin

Schreibe einen Kommentar