【问题标题】：git remove trailing whitespace in new files before commitgit 在提交之前删除新文件中的尾随空格
【发布时间】：2013-10-09 17:21:42
【问题描述】：

我知道可以使用预提交挂钩来删除尾随空格。我有兴趣手动完成。我在这里读到了这个问题：
Make git automatically remove trailing whitespace before committing - Stack Overflow
最接近我想要的答案是the "automatic version" from ntc2：

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

该命令运行良好，但它似乎仅适用于已在 repo 中的文件的更改，而不是新文件。我有一堆新文件，这意味着它们还没有在 repo 中。我想从这些文件中删除空格，所以我尝试添加 -A 而不是 -u 但这没有任何区别。

【问题讨论】：

你的意思是“git add -Ae根本不添加新文件”吗？或者：“文件已添加，但未修复”？
@VonC 它不适用于未跟踪或新的文件（首次添加但尚未提交）。对我来说，它显示 fatal: Empty patch. Aborted. 我正在使用 git 版本 1.8.3.msysgit.0。
@test：如果您对我的原始答案发表评论，或者询问如何使我的命令正常工作，或者链接到您的问题，我会收到通知并且可以告诉您@ 987654327@。但是，SO 很聪明，可以将您的问题放在“相关”部分，所以我今天在编辑答案时看到了它。
vim 用户可能也喜欢这个：stackoverflow.com/questions/356126/…

标签： git whitespace removing-whitespace

【解决方案1】：

如果你使用 emacs，你可以在保存文件之前使用 "M^x delete-trailing-whitespace" 删除它们。（也可以在您的 .emacs 中自定义）

vi 似乎也允许这样做：http://vim.wikia.com/wiki/Remove_unwanted_spaces

【讨论】：

【解决方案2】：

要手动清除最近 3 次提交中的空白，您可以这样做：

git rebase --whitespace=fix HEAD~3

当我在主题分支上工作时，我会跟踪上游分支（通常是这样创建的）

git checkout -b topic -t

这允许我从git rebase 中删除最后一个参数。所以一旦我完成并准备好合并，我可以快速清理整个主题分支：

git ws # 别名为 rebase --whitespace=fix

请注意，与 HEAD~3 示例不同，如果上游分支发生更改，这实际上会将您的更改重新设置为基础！（但这也是我想要的，在我的工作流程中。）

【讨论】：

卢克这行得通，但你知道为什么我不能使用我在问题中询问的命令吗？
恐怕会打败我；但鉴于 whitespace=fix 旨在应用补丁（包括变基），因此出现小问题并不让我感到惊讶。从未跟踪的文件中删除 ws 类似于在 repo 之外编辑文件：这不是 git 的工作。
嘿，这是我刚刚（从基本命令）炮制出来的东西，用于更新分阶段的更改（之后保持添加文件的选择不变）：git commit -mTemp && git stash && git rebase HEAD~ --whitespace=fix && git reset --soft HEAD~ && git stash pop。
谢谢卢克，下次我会试试的
这是一个很好的时刻，如果您还需要修复初始提交，则咒语变为git rebase --whitespace=fix --root（当然，如果您关心存储库的克隆，请不要这样做)

【解决方案3】：

简单修复

你引用的命令

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

如果您首先使用git add -N <files you want to fix> 添加要修复的文件，则可以使用。 add -N 本质上是告诉 Git 假装你之前提交了文件的空版本。

您遇到的错误

我不明白为什么 add -Ae 会出现 fatal: Empty patch. Aborted. 错误，但它看起来像一个错误，因为执行简单的 git add -A . && git diff --cached 表明补丁实际上不应该为空。

更好的空白修复程序

我最近更新了 my answer that you linked to 使用更好的 Git 别名来修复空格。这是该别名的重写使用 Luke's rebase trick 和更少冗余的控制流：

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"

这会修复索引中的空白，同时保留索引，并且让树原封不动。使用此别名，您可以修复未版本化的仓库中的文件与

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

但是，它还可以处理更常见的情况，即在承诺你正在努力。这很复杂，因为即使在索引或树是干净的。

【讨论】：

如果这使树保持不变，这是否意味着索引中的任何空白修复将在git diff 中反向显示，并且在您将受影响的文件添加到索引时将被还原？我想这就是为什么你的管道中有 git reset 的原因，但这似乎抵消了保持树不变的好处。
@jbyler：如果你指的是add、fixws、reset 组合中的reset，那么关键是撤消最初的add。请注意，默认重置为--mixed，它只涉及索引，而不涉及树。
嗨，我今天添加了你的别名并尝试了你更好的空白修复命令行。它最初不起作用，因为我之前启用了 pre-commit 钩子来捕获空格违规。我怀疑发生了什么，所以我禁用了它，然后运行你的命令并且它起作用了。再次感谢！

【解决方案4】：

我喜欢 Luke 的回答，除了您需要手动指定基本提交或使用变基样式的工作流程（其中您的历史被线性化）的限制。我提出了一个不需要额外参数并且不会更改提交图拓扑的修改。作为 shell 命令：

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

或作为 ~/.gitconfig 别名：

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

我更喜欢这个，因为有时我想重新调整我的更改，但如果我认为可能存在合并冲突，我更愿意合并，这样我的原始更改和冲突解决都将记录在历史记录中。这样我就可以稍后再猜测冲突解决方案，并在必要时重做。

鉴于我并不总是变基，我不喜欢将空白修复与变基混为一谈；因此对卢克的回答进行了修改。

此外，我启用了默认的预提交钩子，它会在空白错误时中止：

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

这提供了以下工作流程，我喜欢它，因为它足够手动，我知道发生了什么，但又足够自动化，不会妨碍：

hack hack hack，引入空格错误
尝试提交
由于预提交挂钩，提交失败并出现空白错误
git commit --no-verify 无论如何都要提交
git ws使用别名修复

注意--onto 的用法：这里没有必要，但我发现更容易推理 rebase 是如何工作的。在 Luke 的版本中，HEAD~3 是手册页中的 <upstream>，而在我的版本中，<upstream> 保留其分支实际上游的默认值。不管怎样，你最终都会得到相同的结果。

【讨论】：

--onto 的用法很好。 +1