git entfernen Sie nachträgliche Leerzeichen in neuen Dateien vor dem Commit

Question

Ich weiß, Entfernen von Leerzeichen nach hinten kann mit einem Pre-Commit-Hook erfolgen. Ich bin daran interessiert, es manuell zu tun. Ich lese die Frage hier:
Make git automatically remove trailing whitespace before committing - Stack Overflow
Die Antwort am nächsten, was ich will, ist the "automatic version" from ntc2:

(export VISUAL=: && git -c apply.whitespace=fix add -ue .) && git checkout . && git reset 

Das funktioniert gut, außer es gebieten scheint nur für Änderungen an Dateien, die bereits sind im Repo keine neuen Dateien. Ich habe eine Reihe von Dateien, die neu sind, was bedeutet, dass sie noch nicht im Repo sind. Ich möchte Whitespace aus diesen Dateien entfernen, also habe ich Add-A anstelle von -u versucht, aber das hat keinen Unterschied gemacht.

Answer 1

manuell Leerzeichen aus Ihrem letzten 3 Commits aufzuräumen, können Sie dies tun:

git rebase --whitespace=fix HEAD~3

Wenn ich zu einem Thema Zweig arbeiten, ich habe den Upstream-Zweig Spur (in der Regel durch das so zu schaffen)

git checkout -b topic -t

Das erlaubt mir, das letzte Argument von git rebase fallen zu lassen. Also, wenn ich & bereit bin fertig zu fusionieren, ich das ganze Thema astrein kann schnell mit:

git ws # --whitespace rebase aliased = fix

Beachten Sie, dass im Gegensatz zu dem HEAD ~ 3 Beispiel des Ändert die Änderungen in der Upstream-Zweigstelle, wenn sie geändert wird! (Aber das ist auch das, was ich will, in meinem Workflow.)

Answer 2

Wenn Sie emacs verwenden, können Sie "M^x delete-trailing-whitespace" verwenden, um sie vor dem Speichern der Datei zu löschen. (Es kann auch in Ihrem .emacs angepasst werden)

vi scheint auch dies zu ermöglichen: http://vim.wikia.com/wiki/Remove_unwanted_spaces

Answer 3

Einfach fix

Der Befehl Sie

zitierte

(export GIT_EDITOR=: && git -c apply.whitespace=fix add -ue .) && git checkout . && git reset 

funktioniert, wenn Sie zuerst die Dateien hinzufügen, die Sie mit git add -N <files you want to fix> korrigieren möchten. Die add -N weist Git im Wesentlichen an, so zu tun, als hätten Sie zuvor leere Versionen der Dateien festgelegt.

Fehler hast du

Ich verstehe nicht, warum Sie fatal: Empty patch. Aborted. Fehler bekommen mit add -Ae, aber es sieht aus wie ein Fehler, da Ebene tun git add -A . && git diff --cached zeigt, dass der Patch sollte eigentlich nicht leer sein.

Bessere Leerzeichen fixe

ich vor kurzem für die Befestigung Leerzeichen my answer that you linked to mit einem besseren Git-Alias ​​aktualisiert.Hier ist ein Umschreiben der alias mit Luke's rebase trick und ein weniger redundanten Kontrollfluss:

fixws =!"\ 
    if (! git diff-index --quiet --cached HEAD); then \ 
    \ 
    git diff-files --quiet `git rev-parse --show-toplevel` ; \ 
    export NEED_TO_STASH=$? ; \ 
    \ 
    git commit -m FIXWS_SAVE_INDEX && \ 
    if [ 1 = $NEED_TO_STASH ] ; then git stash save FIXWS_SAVE_TREE; fi && \ 
    git rebase --whitespace=fix HEAD~ && \ 
    git reset --soft HEAD~ && \ 
    if [ 1 = $NEED_TO_STASH ] ; then git stash pop; fi ; \ 
    fi" 

Dies behebt Leerzeichen im Index, während die Index Erhaltung und verlassen den Baum unberührt. Mit diesem Alias ​​können Sie unversionierte Dateien im Repo-fix mit

git add --all :/ && git fixws && git reset 

Aber es ist auch für den häufigeren Fall der Festsetzung up Leerzeichen in einem begehen Sie gerade arbeiten. Es ist kompliziert, weil es auch funktioniert, wenn der Index oder der Baum sauber sind.

Answer 4

Ich mag Lukes Antwort, mit der Ausnahme, dass Sie entweder die Basis-Commit manuell angeben müssen, oder verwenden Sie einen Workflow im Rebase-Stil, wo Ihre Geschichte linearisiert wird. Ich schlage eine Modifikation vor, die kein zusätzliches Argument benötigt und die Topologie Ihres Commit-Graphen nicht ändert. Als Shell-Befehl:

git rebase --whitespace=fix --onto $(git merge-base HEAD @{u}) 

Oder als ~/.gitconfig alias:

ws = "!git rebase --whitespace=fix --onto $(git merge-base HEAD @{u})" 

ich dies vorziehen, weil manchmal möchte ich meine Änderungen rebase, aber wenn ich denke, denke, es könnte eine Zusammenführung sein Konflikt Ich ziehe es vor zu verschmelzen, so dass sowohl meine ursprüngliche Änderung als auch die Konfliktlösung in der Geschichte aufgezeichnet werden. So kann ich später die Konfliktlösung nachholen und bei Bedarf wiederholen.

Da ich nicht immer rebase, ich bevorzuge nicht whitespace-fixing mit Rebasing mischen; daher diese Modifikation zu Lukas Antwort.

Zusätzlich aktiviere ich die Standard-Haken pre-commit, die auf Leerzeichen Fehler abgebrochen:

cp .git/hooks/pre-commit.sample .git/hooks/pre-commit 

Dieses den folgenden Workflow gibt, die Ich mag, weil es manuell genug ist, dass ich weiß, was los ist, aber automatisiert genug nicht in die Quere zu kommen:

1. Hack Hack Hack, einführen Leerzeichen Fehler
2. Versuch mit w
3. verpflichten nicht zu begehen hitespace Fehler aufgrund von pre-commit Haken
4. git commit --no-verify zu begehen sowieso
5. git ws den Alias ​​verwenden

Hinweis auf die Verwendung von --onto zu beheben: Es ist hier nicht nötig, aber ich finde es einfacher, über die Vernunft wie funktioniert das Rebase? In Lukes Version HEAD~3 ist die <upstream> in der man-Seite, während in meiner Version <upstream> behält seinen Standardwert der realen upstream der Branche. Sie landen jedoch mit dem gleichen Ergebnis.