Wiederherstellen der Berechtigungen der Dateien und Verzeichnisse in git, wenn Sie geändert wurden?

Habe ich einen git-checkout. Alle Datei-Berechtigungen sind anders als das, was git denkt, Sie sollte deshalb zeigen, wie geändert.

Berühren, ohne den Inhalt der Dateien (die wollen einfach nur, die Berechtigungen zu ändern) wie kann ich alle Berechtigungen von Dateien zu dem, was git denkt, dass Sie sein sollte?

InformationsquelleAutor Dale Forester | 2010-03-25
  1. 501

    Git verfolgt filepermission und macht änderungen an Berechtigungen beim erstellen von patches mit git diff -p. Also alles, was wir brauchen, ist:

    1. erstellen Sie eine reverse-patch
    2. nur die Berechtigung änderungen
    3. wenden Sie den patch auf unsere Arbeitskopie

    Als ein one-liner:

    git diff -p -R --no-color \
    | grep -E "^(diff|(old|new) mode)" --color=never  \
    | git apply

    können Sie auch hinzufügen, Sie als alias für git-config...

    git config --global --add alias.permission-reset '!git diff -p -R --no-color | grep -E "^(diff|(old|new) mode)" --color=never | git apply'

    ...und du kannst es aufrufen über:

    git permission-reset

    Beachten Sie, wenn Sie die shell ist bash sicher, dass Sie ' statt " Zitate rund um die !git, sonst wird es ersetzt mit dem letzten git Befehl, den Sie lief.

    Thx an @Mixologic für den Hinweis dass, indem Sie einfach mit -R auf git diff das mühsame sed Befehl ist nicht mehr erforderlich.

    • Ich bin in OS X, ist dies nicht funktioniert. Ich hab das problem erkannt, ist im git gelten. Es gilt nicht, die Datei-Berechtigungen ändert.
    • Oh, es hat funktioniert, ich war versucht, von einem anderen Verzeichnis als repository root. git apply und funktioniert nur dort.
    • Gibt es irgendein Grund, warum Sie nicht einfach tun "git diff -p -R" zu tun, anstatt die sed machen es Umgekehrt?
    • Nein. Sieht aus wie ich gerade verpasst. 😉 ...aktualisiert die Antwort.
    • Bitte beachten Sie, dass dies natürlich kehrt auch änderungen innerhalb der Datei. Ich brauchte, um Dateien zu aktualisieren (zusammengestellt js-Dateien), so dass sich der Inhalt ändert bleiben sollte, aber die Datei-Berechtigungen Durcheinander. Die Antwort von Tim Henigan unter einer festen meine Erlaubnis, änderungen, ignorieren (ja, ich bin gezwungen, um windows zu verwenden 🙁 )
    • meine lokalen änderungen, wurden nicht entfernt, wenn mit muhqu Befehl
    • Ich bin immer fatal: unrecognized input
    • Oh, das war verursacht durch inszenierte Veränderungen. git reset vor dem Aufruf den Befehl geholfen 🙂
    • Genial, du bist der Mann.
    • Danke für die Antwort. Ich Stand vor dem gleichen fatal: unrecognized input Nachricht. Stellt sich heraus, meine Farbeinstellungen auf 'immer', was verursacht die Farbe escape-chars werden Teil der Ausgabe auch beim weiterleiten oder in eine Datei schreiben. Wechsel von 'immer' auf 'auto' hat den trick.
    • vielen Dank für den Hinweis. vielleicht lassen Sie es 'immer', wenn Sie fügen nur --no-color zu den git diff Befehl?
    • das war mein Erster Versuch, aber es hat nicht funktioniert, weil, ausgeführt von cygwin habe ich GNU Grep, das nicht unterstützen, dass die fahne. Ich habe jetzt festgestellt, dass er ein --color=never option, dass der trick funktioniert, so... cool! Ich jedenfalls denke, dass 'auto' ist eine bessere option Farbe für grep also werde ich mit dem stick. Danke!
    • ur welcome, ich aktualisierte die Antwort deutlicher.
    • Okay. Ich habe gerade überprüft, die unter Ubuntu und --color=never ist eigentlich die richtige grep-flag, das ist also nicht nur Win/GNU-spezifisch. Super!!!
    • git diff -p nicht immer melden Sie alle Unstimmigkeiten
    • Re fatal: unrecognized input - wenn Sie bereits inszeniert Ihre änderungen vor (Sie sind in der Mitte eines interaktiven rebase für die Instanz bereit, auf weiter) hinzufügen --cached den git diff Befehl
    • dies ist, was ich versucht habe git diff -p -R --no-color -- - Cache | grep -E "^(diff|(alt|neu) - Modus)" --color=never | git apply und bekommen Noch 'fatal: unrecognized input" ich habe versucht, all die tricks oben erwähnt, git reset... Das Ergebnis meiner git diff -p -R --no-color -- - Cache | grep -E "^(diff|(alt|neu) - Modus)"--color=never | git-apply diff --git b/Datei1.out a/Datei1.out ist das erwartete?
    • das diff sollte include-Zeilen beginnend mit "diff", "neue mode" und "alt-Modus". Wenn die neue/alte Linien-Modus fehlen dann entweder git weiß nicht über die Berechtigungen, oder gibt es keine Unterschiede zu Ihnen... Hoffe, das hilft.
    • Ein weiteres +1 auf die Git-Entwickler für eine einfache Aufgabe, und machen es lächerlich kompliziert. Gott bewahre Sie ermöglichen git checkout <file> eigentlich wie erwartet funktionieren.
    • der Befehl oben kann für einige arbeiten, aber nicht, wenn man externe diff-konfiguriert, in diesem Fall fügen Sie --no-ext-diff wie diese: git diff -p -R --no-color --no-ext-diff \ | grep -E "^(diff|(old|new) mode)" --color=never \ | git apply
    • funktioniert wie ein Zauber auf Ubuntu 16.04
    • Ändern Sie diese Befehle, um git -c core.fileMode=true ... um sicherzustellen, Sie arbeiten auch in Umgebungen, in denen Globale oder lokale Optionen deaktiviert haben, prüfen Sie die Datei-Modi.
    • dies hat mein Leben gerettet, danke!
    • git apply schlägt im hintergrund fehl, für mich
    • Wenn Sie fatal: unrecognized input, die du angewandt hast git config core.fileMode false die unten vorgeschlagen. Sollten Sie git config core.fileMode true vor dem ausführen der obige Befehl!
    • fatal: unrecognized input können auch aufgrund git diff keine Ausgabe keine Ergebnisse für mich war, weil ich versuchte, das Update der vorherigen commit einem anderen Entwickler gemacht. Das fertige Ergebnis für die Befestigung des letzten commit sah, wie dieser auf einem mac git diff -p -R --no-color --no-ext-diff HEAD^ HEAD | grep -E "^(diff|(old|new) mode)" --color=never | git apply HINWEIS: die HEAD^ HEAD war, was mir fehlte.
    • Ich muss sagen, wow. Das war genial.

    InformationsquelleAutor muhqu
  2. 101

    Versuchen git config core.fileMode false

    Hinweis: core.fileMode ist groß-und Kleinschreibung!

    Aus der git config Mann Seite:

    core.fileMode

    Wenn false, wird das executable-bit Unterschiede zwischen den index und die working copy werden ignoriert; sinnvoll, über kaputte Dateisysteme wie FAT. Sehen git update-index(1).

    Der Standardwert ist true, außer git-clone(1) oder git-init(1) wird die Sonde und setzen Sie Kern.fileMode false, falls angemessen, wenn das repository erstellt ist.

    • Danke, das ist was ich am Ende tun. Sehr verwendet, um cvs nicht tracking-Berechtigungen, damit dies funktioniert.
    • Ich bin froh, dass das geholfen. Ich erlebte ein ähnliches Problem bei der Freigabe von repos zwischen Linux und Windows. BTW: wenn das Ihre Frage beantwortet, bitte markieren Sie die Antwort als richtig an.
    • Ist es möglich, dass git checkout origin/master - sets Datei-Berechtigungen an den server übergeben, um meine lokale Arbeitskopie? Denn immer wenn ich build V8 für ArangoDB, die Datei Berechtigungen geändert, so dass der Zugriff verweigert wird, um den gesamten build-Ordner (auch mit erhöhten rechten, Windows 7+, dass ist). Ich brauche, um zu lösen alle lokalen Datei-Berechtigungen, bevor ich weiterhin den build-Prozess. Kann core.filemode false das auch fix? Ich vermute, git zu setzen Linux-Berechtigungen auf meinem Windows-Rechner. Die build-Skripte könnte nur erhalten Sie und gelten Sie die gleichen Berechtigungen für neu erstellte Dateien...
    • FYI, der parameter ist nicht case sensitive mehr, als wir sehen können in der Dokumentation Seite Beispiel.
    InformationsquelleAutor Tim Henigan
  3. 8

    Git speichert keine Datei Berechtigungen anderes als ausführbare Skripts. Verwenden Sie so etwas wie git-cache-meta zum speichern der Datei die Besitzrechte und Berechtigungen.

    Git kann nur speichern zwei Arten von Modi: 755 (ausführbar) und 644 (nicht ausführbare). Wenn Ihre Datei wurde 444 git speichert es hat 644.

    • Sorry, aber das ist falsch. Git tut, in der Tat, track-Berechtigungen.
    • Es ist in etwa korrekt, siehe git.wiki.kernel.org/index.php/ContentLimitations. Die genauen Berechtigungen, die gesetzt scheinen, basierend auf der server - & möglicherweise ist der client umask sowie eine config-Einstellung finden Sie unter stackoverflow.com/a/12735291/125150.
    • Nein, tut es nicht. Kann nicht glauben, dass dein Kommentar so viele upvotes.
    InformationsquelleAutor kroger
  4. 6
    git diff -p \
| grep -E '^(diff|old mode|new mode)' \
| sed -e 's/^old/NEW/;s/^new/old/;s/^NEW/new/' \
| git apply

    wird in den meisten Fällen funktionieren, aber wenn Sie mit externen diff-Tool wie meld installiert haben, müssen Sie --no-extern-diff

    git diff --no-ext-diff -p \
    | grep -E '^(diff|old mode|new mode)' \
    | sed -e 's/^old/NEW/;s/^new/old/;s/^NEW/new/' \
    | git apply

    nötig war, in meiner situation

    • Vielen Dank für die tolle Antwort, einen schönen Tag noch 😉
    InformationsquelleAutor zainengineer
  5. 0

    Könnten Sie auch versuchen, eine pre/post-checkout hook könnte den trick tun.

    Finden Sie unter: Customizing Git - Git-Hooks

    InformationsquelleAutor Doug
  6. -1

    Die einfachste Sache zu tun ist, einfach ändern Sie die Berechtigungen zurück. Wie @kroger festgestellt git nur Spuren executable-bits. So werden Sie wahrscheinlich nur brauchen, um ausführen chmod -x filename um es zu beheben (oder +x wenn es das ist, was benötigt wird.

    • Hier ist ein Beispiel aus git show: diff --git a/OpenWatch/src/org/ale/openwatch/fb/FBUtils.java b/OpenWatch/src/org/ale/openwatch/fb/FBUtils.java index cd6fa6a..e5b0935 100644, Die wenig Fett, gibt es die Datei-Berechtigungen.
    • Das einfachste schien mir auch. Leider, ich hatte das gleiche problem wie Conrado - ich konnte es nicht ändern Genehmigung von 100644 zu 100755. Ich glaube nicht, dass Sie verdienen einen downvote; Git sollte nach unten gestimmt. Es ist so kaputt auf so viele Arten auf so vielen verschiedenen Ebenen...
    InformationsquelleAutor Pat Notz
  7. -1

    git diff -p verwendet in muhqu Antwort zeigt möglicherweise nicht alle Abweichungen.

    • gesehen, das in Cygwin für Dateien, die ich nicht selbst
    • - Modus änderungen werden komplett ignoriert, wenn core.filemode ist false (das ist der Standard für MSysGit)

    Dieser code liest die Metadaten direkt statt:

    (set -o errexit pipefail nounset;
git ls-tree HEAD -z | while read -r -d $'\0' mask type blob path
do
    if [ "$type" != "blob" ]; then continue; fi;
    case "$mask" in
    #do not touch other bits
    100644) chmod a-x "$path";;
    100755) chmod a+x "$path";;
    *) echo "invalid: $mask $type $blob\t$path" >&2; false;;
    esac
done)

    Non-production-grade-one-liner (ersetzt Masken vollständig):

    git ls-tree HEAD | perl -ne '/^10(0\d{3}) blob \S+\t(.+)$/&& { system "chmod",$1,$2 || die }'

    (Credit für "$'\0'" geht http://transnum.blogspot.ru/2008/11/bashs-read-built-in-supports-0-as.html)

    InformationsquelleAutor ivan_pozdeev
  8. -2

    Den etckeeper - Werkzeug behandeln können Berechtigungen und mit:

    etckeeper init -d /mydir

    Können Sie es verwenden, für andere Verzeichnisse als /etc.

    Installieren, indem Sie mit Ihrem Paket-manager oder Quellen aus dem oben genannten link.

    • Was braucht es, legen Sie die Berechtigungen zu? Wenn es nicht Lesen Git-Metadaten oder rufen Sie Git, es nicht zu tun, was der OP verlangt.
    • und.... der link ist kaputt
    InformationsquelleAutor MoreIT
Schreibe einen Kommentar