git pull总是失败，但是git fetch/merge很好 [英] git pull always fails, but git fetch/merge are fine

问题描述

当我在任何存储库中git pull时，总是会收到以下合并错误:

When I git pull in any repository, I always get the following merge error:

aetherboard:shwangster shwangster$ git pull -v
From github.com:sirspinach/shwangster
 = [up to date]      master     -> origin/master
merge: 012012012012012012012012012012012012012012012012012012012012 - not
something we can merge

另一方面，git fetch和git merge origin/master就像一个吊饰一样工作.因此，我能够解决这一问题已有一段时间了.但是，我今天需要更新brew，并且同样的错误使我无法这样做.

On the other hand, git fetch and git merge origin/master work like a charm. So I've been able to work around this problem for a while. However, I needed to update brew today, and the same error prevents me from doing that.

这是brew update的输出，它再次显示git试图与神秘的0120120120120...合并.

Here is the output from brew update, which shows git again attempting to merge with the mysterious 0120120120120....

aetherboard:gitrepos shwangster$ brew update
merge: 012012012012012012012012012012012012012012012012012012012012 - not 
something we can merge
Error: Failure while executing: git pull -q origin refs/heads/master:refs/remotes/origin/master

推荐答案

Kaz在评论中指出了另一个(几乎完全重复)的问题的线索，当从中删除pyenv时，问题就消失了. $PATH.

There's a clue in the other (pretty much exact duplicate) question that Kaz noted in a comment, that the problem went away when pyenv was taken out of $PATH.

这是pull脚本中的一部分，它提取了FETCH_HEAD跟踪并将其转换为git merge的参数(或在进行重新基准拉入时转换为git rebase的参数):

Here's the bit from the pull script that takes the FETCH_HEAD trace and turns it into an argument to git merge (or to git rebase when doing a rebasing pull):

merge_head=$(sed -e '/  not-for-merge   /d' \
        -e 's/  .*//' "$GIT_DIR"/FETCH_HEAD | \
        tr '\012' ' ')

(顺便说一下，请注意那些是not-for-merge之前和之后的制表符，并且是sed的第二个-e参数.剪切并粘贴通常将制表符转换为空格，并在此处进行了操作.)

(By the way, note that those are tabs before and after not-for-merge and in the second -e argument to sed. Cut-and-paste generally turns tabs into spaces, and did here.)

我想象sed部分工作正常，并且失败发生在tr调用上.实际上，无论使用什么tr，都只是吐出012字符串(总共60个字符，或20个三字符组实例)，不确定sed输出是或应该是40个字符的SHA-1).

I imagine the sed part is working correctly and the failure occurs with the tr invocation. In fact, it looks like whatever tr is being used, is simply spitting out the 012 string (for a total of 60 characters, or 20 instances of the three-character group—not sure how that happens given that the sed output is, or should be, a 40-character SHA-1).

如果您的外壳是sh或bash，请查看以下内容:

If your shell is sh or bash, see what:

$ type tr

打印.如果使用csh变体，则which tr将向您显示它将运行的内容. (我不确定用于dash和zsh的内容是什么.)如果您得到的不是/usr/bin/tr以外的内容，则可能是问题所在. (如果确实得到/usr/bin/tr，请查看type sed或which sed的内容:这些应为/usr/bin/sed.)

prints. If you use a csh variant, which tr will show you what it will run. (I'm not sure off-hand what to use for dash and zsh.) If you get something other than /usr/bin/tr, that may explain the problem. (If you do get /usr/bin/tr see what type sed or which sed says: these should be /usr/bin/sed.)

这篇关于git pull总是失败，但是git fetch/merge很好的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！