Verwendung von Git für die Arbeit mit Subversion: Änderungen an verfolgten Dateien ignorieren

Question

Ich arbeite derzeit mit einem Subversion-Repository, aber ich verwende Git, um lokal auf meinem Rechner zu arbeiten. Das macht die Arbeit viel einfacher, aber es macht auch einige der schlechten Verhaltensweisen im Subversion-Repository deutlich, und das bereitet mir Probleme.

Nach dem Herunterziehen des Codes findet ein etwas komplexer lokaler Build-Prozess statt, bei dem eine Reihe von Dateien erstellt (und leider auch geändert) werden. Offensichtlich sind diese Änderungen nicht dazu gedacht, zurück in das Repository übertragen zu werden. Unglücklicherweise ändert der Erstellungsprozess tatsächlich einige nachverfolgte Dateien (ja, höchstwahrscheinlich, weil jemand diese Erstellungsartefakte irgendwann versehentlich an das Subversion-Repository übergeben hat). Da es sich dabei um Änderungen handelt, hilft es mir nicht, sie zu meiner Ignorieren-Datei hinzuzufügen.

Ich kann es vermeiden, diese Änderungen zu überprüfen, indem ich sie einfach nicht bereitstelle oder übertrage, aber wenn ich nicht bereitgestellte lokale Änderungen habe, kann ich nicht rebasen, ohne sie vorher zu bereinigen.

Ich würde gerne wissen, ob es eine Möglichkeit gibt, zukünftige Änderungen an einer Reihe von verfolgten Dateien zu ignorieren? Oder gibt es eine andere Möglichkeit, das Problem, das ich habe, zu lösen, oder muss ich demjenigen, der diese Dateien eingecheckt hat, einfach sagen, dass er sie bereinigen soll?

Answer 1

Comme Nathan sagte ist es klug, diese Dateien zu bereinigen (ihre Verfolgung aufzuheben).

Aber wenn Sie verfolgte Dateien ignorieren müssen (was nicht der native Weg von Git ist, wenn es darum geht, Dateien zu ignorieren: Git ignoriert nur nicht verfolgbar Dateien) können Sie einen Prozess einrichten, der den Inhalt der Dateien, die Sie ignorieren wollen, kopiert und bei der Übergabe wiederherstellt.

Anfangs glaubte ich, dass ein Verschmutzungs-/Reinigungsprozess das ist ein gitattributes-Filtertreiber könnte den Zweck erfüllen:

, wobei:

• der Smudge-Prozess erstellt eine Kopie dieser Dateien (bei der Aktualisierung des Arbeitsbaums)
• Während der Erstellung werden einige Änderungen vorgenommen.
• Der Clean-Schritt (während der Übertragung) löscht den Inhalt der Dateien mit der in Schritt 1 erstellten Kopie.

ABER, als in diesem Beitrag erklärt Das würde bedeuten, dass man diese Möglichkeit missbraucht. zustandslos Datei Inhalt Transformation durch Hinzufügen eines zustandsbehafteten Kontexts (d. h. des vollständigen Pfadnamens der zu säubernden/zu reinigenden Datei).
Und das wird von J.C. Hamano ausdrücklich untersagt:

Obwohl ich zunächst in Erwägung gezogen hatte, die " %P "mit Pfadnamen, habe ich mich letztendlich dagegen entschieden, um Leute davon abzuhalten, den Filter für eine zustandsabhängige Konvertierung zu missbrauchen, die die Ergebnisse abhängig von Zeit, Pfadnamen, Commit, Branch und so weiter ändert.

und sogar Linus Torvalds hatte einige Vorbehalte zu der Zeit über den gesamten Mechanismus:

Ich muss sagen, dass ich offensichtlich kein großer Fan von Spielen bin, aber die Diffs sind sehr sauber.

Sind sie tatsächlich nützlich? Ich weiß es nicht. Ich bin ein bisschen nervös, was das für die tatsächlichen Nutzer der Funktion bedeutet, aber ich muss zugeben, dass ich von einer sauberen Implementierung begeistert bin.

Ich vermute, dass wir dadurch einige Beschwerden loswerden, aber ich également Ich habe den Verdacht, dass die Leute sich mit so etwas selbst in die Pfanne hauen und uns dann die Schuld geben und einen riesigen Schmerz verursachen, wenn wir das unterstützt haben und die Leute eine "erweiterte Semantik" wollen, die nicht mehr sauber ist.

Aber ich bin mir nicht sicher, wie stichhaltig dieses Argument wirklich ist. Ich glaube zufällig an die Philosophie "Gebt ihnen einen Strick". Ich denke, dass man sich damit wahrscheinlich gewaltig in die Nesseln setzen kann, aber hey, jeder, der das tut, hat nur sich selbst die Schuld gegeben

---

Der richtige Ort für das Hinzufügen einer Art von Speicher-/Wiederherstellungsmechanismus (und das effektive Ignorieren aller Änderungen an einem Satz von Verfolgt Dateien in Git) wäre in Häkchen :

• post-checkout : wird aufgerufen, wenn ein Git-Checkout ausgeführt wird, nachdem der Arbeitsbaum aktualisiert wurde. Dort können Sie ein Skript ausführen, das alle zu ignorierenden Dateien sammelt und sie irgendwo speichert.

• pre-commit : Sie können ein zweites Skript ausführen, das den Inhalt dieser Dateien wiederherstellt, bevor Sie die vorgeschlagene Commit-Log-Nachricht abrufen und einen Commit durchführen.

Answer 2

Wenn es sich nicht um einen ernsthaften politischen Hirnschaden handelt, ist das Entfernen der Artefakte aus der Versionskontrolle der richtige Schritt. (Oder besser gesagt, der "zweckmäßigste" Schritt, es ist immer der richtige Schritt.)

Mir ist nicht bekannt, wie man Git anweisen kann, Änderungen an verfolgten Dateien zu ignorieren.