git rebase -i HEAD~7 -- 在编辑器中只显示“noop”

git rebase -i HEAD~7 -- showing only "noop" in editor

提问by Ryan Long

I am trying to squash a commit which is at HEAD into one that is a few back. When I run git rebase -i HEAD~7, however, I am presented with just a noopin the editor! I am totally confused about how this is supposed to work.

我试图将一个位于 HEAD 的提交压缩到一个后面的提交中。git rebase -i HEAD~7然而，当我运行时，我noop在编辑器中只看到一个！我对这应该如何工作感到非常困惑。

I am working in a branch (cleanup) that I created (using checkout -b cleanup ...on the SHA1 I found in reflog) after I had my first rebaseexperience and I accidentally deleted all of those commits; point is, I am not sure what the branch's parent is (if that matters, here).

在我第一次体验之后cleanup，我在我创建的分支 ( ) 中工作（在我在 中checkout -b cleanup ...找到的 SHA1 上使用reflog），但rebase我不小心删除了所有这些提交；关键是，我不确定分支的父级是什么（如果这很重要，请看这里）。

I am simply trying to do what I have read about many times: I want to modify slightly some commited code that isn't the most recent commit. Whether that's an application for "squashing" or just amending it when I get to that point, I don't know.

我只是试图做我多次阅读的内容：我想稍微修改一些不是最近提交的提交代码。我不知道这是一个“挤压”的应用程序还是只是在我到达那个点时对其进行修改。

I am also seeing this on STDOUT as the editor starts after running the rebase command shown above:

当编辑器在运行上面显示的 rebase 命令后启动时，我也在 STDOUT 上看到了这一点：

$ git rebase -i HEAD~7
usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]
  limiting output:
    --max-count=<n>
    ...

In addition to the HEAD~7reference, I have tried specifying the entire SHA1, and different refspecs to local and remote branches. Same result for everything...

除了HEAD~7引用之外，我还尝试指定整个 SHA1，以及对本地和远程分支的不同引用规范。一切都一样的结果......

What am I missing? Thanks for your help!

我错过了什么？谢谢你的帮助！

---

---

Edit:

编辑：

$ git log --oneline HEAD~7..HEAD
d0fd20e temp Fix resume_cities table
ea2ffdf Fix db/seeds.rb to reflect recent database structure modifications
dbd2b8b Add several models/scaffolds that go along with the Geonames tables
9759091 Fix name of the ResumeSkill model file.
3fc3134 Added the SHA1 for the previous commit to the comments on the migration, to help link back to that.
bacbeb2 Consolidate database migrations! READ ME!
0c49a57 Moved back to gem versions of linkedin, omniauth, and twitter

It's the bacbeb2commit I want to amend with the d0fd20e

这是bacbeb2我想要修改的提交d0fd20e

---

---

Per the recommendation of @MarkLongair, I added set -xto /usr/lib/git-core/git-rebase--interactiveand saw the following strange output:

每@MarkLongair的推荐下，我加入set -x到/usr/lib/git-core/git-rebase--interactive和看到如下奇怪的输出：

$ git rebase -i HEAD~7

[... output muted for brevity, see the full output, here: http://gist.github.com/1163118]
+ read -r shortsha1 rest
+ sed -n s/^>//p
+ git rev-list --no-merges --cherry-pick --pretty=oneline --abbrev-commit --abbrev=7 --reverse --left-right --topo-order 2c51946812a198ca908ebcad2308e4b8274624b3...d0e9ff6d9c1f8bc374856ca2a84ad52d6013b5bf
usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]
  limiting output:
    --max-count=<n>
    --max-age=<epoch>
    --min-age=<epoch>
    --sparse
    --no-merges
    --remove-empty
    --all
    --branches
    --tags
    --remotes
    --stdin
    --quiet
  ordering output:
    --topo-order
    --date-order
    --reverse
  formatting output:
    --parents
    --children
    --objects | --objects-edge
    --unpacked
    --header | --pretty
    --abbrev=<n> | --no-abbrev
    --abbrev-commit
    --left-right
  special purpose:
    --bisect
    --bisect-vars
    --bisect-all
+ test t = 
+ test -s /home/ryan/Projects/social-jobs/.git/rebase-merge/git-rebase-todo
+ echo noop
[...]

I say, 'strange output' because if I run the rev-listcommand directly from my shell, it works as expected:

我说“奇怪的输出”是因为如果我rev-list直接从我的 shell运行命令，它会按预期工作：

$ git rev-list --no-merges --cherry-pick --pretty=oneline --abbrev-commit --abbrev=7 --reverse --left-right --topo-order 2c51946812a198ca908ebcad2308e4b8274624b3...d0e9ff6d9c1f8bc374856ca2a84ad52d6013b5bf
>0c49a57 Moved back to gem versions of linkedin, omniauth, and twitter
>bacbeb2 Consolidate database migrations! READ ME!
>3fc3134 Added the SHA1 for the previous commit to the comments on the migration, to help link back to that.
>9759091 Fix name of the ResumeSkill model file.
>dbd2b8b Add several models/scaffolds that go along with the Geonames tables
>ea2ffdf Fix db/seeds.rb to reflect recent database structure modifications
>d0e9ff6 !temp Fix resume_cities table !temp

采纳答案by Ryan Long

This issue was caused bymy .bashrc setting IFS:

这个问题是由我的 .bashrc设置 IFS引起的：

# remove the space character from IFS
# (http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html#IFS)
IFS="`printf '\n\t'`"

I cannot remember at all why I put that in there. I'm sure it had something to do with 'fixing UNIX/Linux filenames' as indicated by my inclusion of that URL. Dunno.

我完全不记得我为什么把它放在那里。我确定它与我包含该 URL 所指示的“修复 UNIX/Linux 文件名”有关。不知道。

Regardless, though, I removed that statement and: POOF! No more problem!

不过，无论如何，我删除了该声明并：POOF！没有问题了！

Thanks so much to @MarkLongair for his help!

非常感谢@MarkLongair 的帮助！

回答by Mark Longair

Update:There's an explanation for this behaviour at the end of my answer, but I've left the debugging suggestions here in case they are of use to anyone.

更新：在我的回答末尾有对这种行为的解释，但我把调试建议留在这里，以防它们对任何人有用。

---

---

I'm not sure I have a real answer here, but I'll explain what's happening to the best of my understanding. When invoked as git rebase -i HEAD~7, git should only output noopto .git/rebase-merge/git-rebase-todoif that file is empty or does not exist. We know that this isn't a permissions problem, since that file (containing "noop" and the commented lines) is successfully created as a result. The fact that you see an error from git rev-liston the terminal also suggests that the problem is really due to how git rev-listis invoked. In git v1.7.4.1, with the command line you quote, the list of commits to include should be found from the following:

我不确定我在这里有一个真正的答案，但我会尽我所能解释发生了什么。当作为调用git rebase -i HEAD~7，混帐应该只输出noop到.git/rebase-merge/git-rebase-todo该文件是否为空或不存在。我们知道这不是权限问题，因为该文件（包含“noop”和注释行）因此成功创建。您git rev-list在终端上看到错误这一事实也表明问题确实是由于git rev-list调用方式造成的。在 git v1.7.4.1 中，使用您引用的命令行，应从以下位置找到要包含的提交列表：

git rev-list --no-merges --cherry-pick --pretty=oneline --abbrev-commit \
    --abbrev=7 --reverse --left-right --topo-order HEAD~7...HEAD

Note that this is somewhat different from what is suggested by the man page (git log <upstream>..HEAD) since the range uses ...instead of ..

请注意，这与手册页 ( git log <upstream>..HEAD) 的建议有所不同，因为范围使用...而不是..

I would guess, since you see an error from git rev-list, that this is the problematic command. Could you try that, and see what the output is? If that seems to work, then I suspect that there is an earlier error that causes this command line to be malformed. Since the interactive rebase is implemented as a shell script, you can fairly easily investigate this by editing the script with sudo editor /usr/lib/git-core/git-rebase--interactiveand adding set -xat the top, something like:

我猜，既然您看到了来自 的错误git rev-list，那么这是有问题的命令。你可以试试看，看看输出是什么？如果这似乎有效，那么我怀疑有一个较早的错误导致此命令行格式错误。由于交互式 rebase 是作为 shell 脚本实现的，因此您可以通过编辑脚本sudo editor /usr/lib/git-core/git-rebase--interactive并set -x在顶部添加以下内容来轻松调查此问题，例如：

#!/bin/sh
set -x
#
# Copyright (c) 2006 Johannes E. Schindelin

# SHORT DESCRIPTION
[...]

Then if you try running git rebase -i HEAD~7, you should see every command that the script is running, and possibly see what's wrong with the git rev-listinvocation.

然后，如果您尝试 running git rebase -i HEAD~7，您应该会看到脚本正在运行的每个命令，并且可能会看到git rev-list调用有什么问题。

I hope that's of some help.

我希望这会有所帮助。

---

---

Update:It turns out thatthe problem here was the the questioner had IFSset to only include tab and newline, rather than the default of space, tab and newline.

更新：它原来，这里的问题是提问已IFS设置为只包括标签和换行，而不是空格，制表符和换行的默认。

This causes a problem in the line in git-rebase--interactivebeginning:

这会在git-rebase--interactive开头的行中导致问题：

git rev-list $MERGES_OPTION --pretty=oneline [...]

... since MERGES_OPTIONis set to --no-merges --cherry-pick. With the default value of IFS(which includes space) this will be split into two parameters after the variable is substituted. However, with an IFSthat doesn't include space, --no-merges --cherry-pickwill be interpreted as a single, and obviously unknown, argument, causing the git rev-listusage message and empty output being passed on in the script.

... 因为MERGES_OPTION设置为--no-merges --cherry-pick. 使用默认值IFS（包括空格），这将在变量被替换后拆分为两个参数。但是，对于IFS不包含空格的 ，--no-merges --cherry-pick将被解释为单个显然未知的参数，从而导致git rev-list在脚本中传递使用消息和空输出。

A good puzzle :)

一个很好的拼图:)