10

Ich habe ein Projekt, das in TFS gestartet wurde, dann nach Git verschoben. Leider hat der Typ, der es nach Git verschoben hat, einfach die aktuellen Dateien eingecheckt, anstatt git-tfs zu benutzen. Ich versuche, seine neuen Commits in Git zusätzlich zu den Commits, die ich aus TFS mit git-tfs gezogen habe, neu zu setzen.Warum zeigt Git einen Konflikt zwischen zwei scheinbar identischen hinzugefügten Dateien?

Um dies zu tun, bin ich einfach seine Commits auf die Git-TFS-Commits neu zu rebasing. (Ich weiß, das wird entfernte Git Zweige, aber wir sind ein kleines Team und es wird in Ordnung sein. Ich habe auch versucht Rosinenpicking statt, aber ich habe das gleiche Problem.)

Das Problem, das ich ' m läuft in einer Reihe von Konflikten, die wie folgt aussehen:

<<<<<<< HEAD 
namespace OurNiftyProject 
{ 
    public enum CardType 
    { 
     Visa = 0, 
     MasterCard = 1 
    } 
} 
||||||| merged common ancestors 
======= 
namespace OurNiftyProject 
{ 
    public enum CardType 
    { 
     Visa = 0, 
     MasterCard = 1 
    } 
} 
>>>>>>> Add a bunch of stuff. 

Es scheint, dass dies ein Konflikt zwischen einem von der TFS Seite verpflichten, die diese Dateien und eine Festschreibung auf der Git Seite hinzugefügt, die sie hinzugefügt (wie der Git Repo leer anfing).

Die logische Sache wäre vielleicht, dieses Commit zu überspringen, aber es gibt ein paar Dateien (sagen wir zehn von ein paar hundert), die neu sind. Diese verursachen natürlich keine Konflikte.

Warum kann Git nicht selbst herausfinden, dass die beiden Dateien identisch sind? Auch wenn ich beim Rebase --ignore-whitespace verwende, zeigt Git immer noch Dutzende solcher Dateien, die identisch zu sein scheinen. Ich weiß nicht, wie ich das lösen soll.

+0

Gibt 'diff' Ihnen auch einen Unterschied? – Reactormonk

+4

Könnte es Unterschiede zwischen den Zeilenenden geben? – ebneter

+0

Trailing whitespaces vielleicht –

Antwort

9

Es sollte über Zeilenende-Unterschiede sein, wie ebneter Kommentare.
Ich habe ausführlich schon vor langer Zeit, wie git merge zu ignorieren diese Unterschiede nicht gut war (im Gegensatz zu Whitespaces Unterschieden gegen):
Is it possible for git-merge to ignore line-ending differences?

Die warum eine konsequente EOL-Konvertierung Politik ist notwendig für diese Repository in heterogenen Umgebung.
Siehe "Distributing git configuration with the code".

+0

Betrachtet Git tatsächlich Zeilenendungsunterschiede, die sich von Leerraumunterschieden unterscheiden !? Ich dachte Zeilenenden * waren * Whitespace! –

+0

@Kyralessa: nicht genau. http://gitester.livejournal.com/28862.html erwähnt 'cr-at-eol': mit' trailing-space', wird nicht ausgelöst, wenn das Zeichen vor einem solchen Wagenrücklauf kein Leerzeichen ist, sondern * nicht standardmäßig aktiviert ist *. – VonC

5

Ich mache eine ähnliche Sache und habe gerade "-X ignore-space-at-eol" gefunden. Es ist sowohl für die Zusammenführung als auch für die Umbenennung verfügbar. Scheint das Richtige zu tun, macht es aber für mich langsam.

+1

Vielleicht haben sie eine Beschleunigung gefunden, denn das Hinzufügen der Flagge verlangsamt mich nicht. git Version 1.9.5.msysgit.0 – AnneTheAgile

1

Ich bin gerade auf dieses Problem gestoßen, gefolgt von diesem Post, nur um zu erkennen, dass es auch ein Zeilenende-Szenario für mich ist.

Also FWIW, dies passierte in meinem Fall, weil ich "Windows Style Line Endings" verwendet habe, aber irgendwann für ein anderes Projekt habe ich es auf "Use Unix style line endings" umkonfiguriert (diese Konfigurationen sind verfügbar im Git Setup-Programm).

Rückkehr zu „Use Windows-Stil Zeilenende“ das Problem gelöst, ohne die Verwendung von „--ignore-Leerzeichen“

1

Wenn Sie aufgrund unterschiedlicher Zeilenende unsichtbarer Veränderungen ausschließen können, können Sie, wenn die Dateien überprüfen verschiedene Modi haben (zB wenn das ausführbare Bit gesetzt ist). Git zeigt die vollständige Datei in einem diff, wenn sich der Dateimodus ändert.

Verwandte Themen