1

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

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.

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
twink_ml
  • 512
  • 3
  • 14
  • I'm not sure exactly what's wrong, but take a look at the contents of the file `FETCH_HEAD` (in the `.git` directory) after a failed `git pull`. The `pull` command runs `fetch` with extra arguments that tell it to leave traces in `FETCH_HEAD`, and then uses those traces to run `git merge`. There's something goofy with those traces, causing the `pull` script to issue a faulty `merge` command. – torek Dec 21 '14 at 19:23
  • Thanks for your help, torek. Here's the contents of `FETCH_HEAD` from two different repositories after I attempted git pull: 1. `ecbacbe7d1b15058065d8856328cecba8141b1d0 branch 'master' of github.com:sirspinach/shwangster` 2. `206b62d28091d98909947ad32085a15fa463d7f5 not-for-merge branch 'master' of github.com:sirspinach/cs61a-scheme` – twink_ml Dec 21 '14 at 19:38
  • Exact duplicate of: http://stackoverflow.com/questions/25271075/git-pull-always-returns-not-something-we-can-merge – Kaz Dec 21 '14 at 19:58
  • Interesting... the file contents are sane, the problem must be in the choice of merge head. Looks like `tr '\012' ' '` has gone wrong. – torek Dec 21 '14 at 21:23

1 Answers1

1

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.

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' ' ')

(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.)

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).

If your shell is sh or bash, see what:

$ type tr

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.)

torek
  • 448,244
  • 59
  • 642
  • 775
  • Thanks a bunch! It turned out that the `tr` that git had been expecting was replaced by [something else](https://github.com/itsnauman/termrule) that I installed a long time ago. – twink_ml Dec 21 '14 at 21:52