Skip to end of metadata
Go to start of metadata

Ich will jetzt gar nicht über die Gründe reden und dass man bitte nur ASCII Dateinamen verwenden sollte ... JA: ASCII das Ding mit den 128 Zeichen ABER

Es soll ja passieren (), dass es Dateien mit Umlauten im Namen in ein Repo schaffen. Dann arbeiten zwei Entwickler auch noch mit unterschiedlichen Systemen (bestenfalls Windows und Linux oder Mac).

Und Schon haben wir den Salat..

bash:$ ls -1 img
/img/r%FCckblick.png
/img/rueckblick.png
/img/rückblick.png

oder

bash:$ ls -1 img
/img/r%FCckblick.png
/img/rueckblick.png
/img/rückblick.png

=> zum Beispiel sehen wir nun soetwas:

bash:$ git st
?? img/r%FCckblick.png
?? "img/ru\314\210ckblick.png"
1

 

"Alter, sollte die Datei nicht "rückblick.png" heißen?!"

und warum werden die nun so komisch angezeigt?

Ich kann die auch nicht mehr löschen:

 

 

Was ist passiert

a) Benutzer A hat die Datei unter Windows (CP1252 was eine Abwandlung von ISO-8859-15 ist) mit dem Umlaut "ü" gespeichert und committet. Bis hierhin: Kein Problem

ein ü hexadezimal in latin1 (CP1252, ISO-8859-1/15) betrachtet bedeutet: FC

Das erklärt dann die git status Anzeige mit: r%FCckblick

 

b) Interne Repository-Verwaltung von git ist in der Regel immer in utf8

i18n.commitEncoding

    Character encoding the commit messages are stored in; git itself does not care per se, but this information is

    necessary e.g. when importing commits from emails or in the gitk graphical history browser (and possibly at other

    places in the future or in other porcelains). See e.g.  git-mailinfo(1). Defaults to utf-8.

aus einem ISO Umlaut ü Zeichen (FC) wird in UTF-8 also ungültiges ein Zeichen.

c) Nun checkt Kollege B das ganze bei sich aus, diesmal auf einer Linux / Mac Maschine mit UTF-8 Umgebung.

  • Entweder er bemerkt nun selbst dass da eine Datei ist die falsch benamt ist und benennt Sie manuell um

oder aber

 

 

d) Kollege B hat nun eine scheinbar neue Datei denn für git sind

  • rückblick.png
    alias
    r%FCckblick.png

und

e) committet man nun diese neue Datei, taucht diese wiederrum beim Kollegen A unter Windows als fehlerhaft-kodierte Datei(name) auf

 

Das Problem

Beide haben Schwierigkeiten die Datei in git zu entfernen.

Vorab: Wirklich sauber gelöst habe ich es bisher immer nur unter einer *nix Maschine, unter Windows war mir das versagt da Windows und verschiedene Zeichnkodierungen sich gar nicht vertragen (übrigens auch ein Grund warum ich Windows als Entwickler hasse)

Die Lösung

Ist eigentlich trivial:

  1. Ein UTF-8 Terminal schnappen
  2. NICHT versuchen die Dateinamen zu kopieren und dann mit git rm zu löschen, das schlägt meist fehl
  3. stattdessen manuell - jaja so ganz ohne C&P und Tab-Completion!!! - den Dateinamen eintippen
    ^^ git rm natürlich davorsetzen (wink)
  4. nun sollte schonmal die UTF-8 schreibweise weg sein:

    bash:$ git st
    D  "img/ru\314\210ckblick.png"
    ?? "img/r\374ckblick.png"
  5. Nun das Terminal auf ISO (latin1) umstellen
  6. Das prozedere wiederholen: sprich: den Dateinamen schlicht nochmal eintippen und löschen lassen:

    bash:$ git st
    D  "img/ru\314\210ckblick.png"
    D  "img/r\374ckblick.png"
  7. Glückwunsch! nun noch committen (wink)

 

 

 


 

Footnotes
Ref Notes
1
git st == git status -s

mit

git config core.quotepath false

core.quotepath

    The commands that output paths (e.g.  ls-files, diff), when not given the -z option, will quote "unusual"

    characters in the pathname by enclosing the pathname in a double-quote pair and with backslashes the same way

    strings in C source code are quoted. If this variable is set to false, the bytes higher than 0x80 are not quoted

    but output as verbatim. Note that double quote, backslash and control characters are always quoted without -z

    regardless of the setting of this variable.


(vgl. http://code.childno.de/marcel/src/master/.gitconfig)
2 gleiches Problem, anderes Beispiel: https://github.com/owncloud/core/issues/1780