90

After upgrading to OSX 10.10 Yosemite Beta, running git pull is returning the following error:

/Library/Developer/CommandLineTools/usr/libexec/git-core/git-pull: line 11: git-sh-setup: No such file or directory

I've checked the referenced git-core directory and the git-sh-setup.sh is there.

Other git commands are working exactly as expected

Ravi Bhatt
  • 1,930
  • 1
  • 14
  • 27
meghaphone
  • 1,012
  • 1
  • 8
  • 8

10 Answers10

100

I think the cleanest solution for this for now is to change the initial command in your iTerm session to be

/usr/bin/login -f <your user name>

This fixes the issue for me.

A further data point for analysis of the issue: It seems that in 10.10, multiple copies of the PATH environment variable exist and subshells seem to prefer the second copy.

You can reproduce this by launching any cocoa application on the console as launched by iTerm. You'll get a warning that looks like this:

2014-06-04 19:23:09.859 gitx[14676:362580] *** -[NSProcessInfo environment]: Warning: duplicate definition for key 'PATH' found in environment -- subsequent definitions are ignored.  The first definition was '(the path I have configured in my shell)', the ignored definition is '/usr/bin:/bin:/usr/sbin:/sbin'.

I believe this to be a problem in 10.10 and not iTerm, but something iTerm is doing is causing it to manifest itself (this doesn't happen in Terminal.app)

Update: This is caused by iTerm doing "interesting" stuff to the environment. Update to the official release of iTerm 2.0 to make this problem go away.

pilif
  • 12,548
  • 5
  • 34
  • 31
  • 6
    This should be the correct answer, amazing fix. However, I set the command to `/usr/bin/login -f $USER`, just so I can have the same profile on multiple accounts :) – cadlac Jun 05 '14 at 06:48
  • Also, a much easier test is to just run env: before logging in it shows 2 PATH variables. Makes a conditional statement easy `[[ $(env | grep -c PATH) < 2 ]] || /usr/bin/login -f $USER` – cadlac Jun 05 '14 at 07:16
  • 12
    Apparently, bash removes all duplicated environment variables. So, if you set the command to `/bin/bash -c /bin/zsh` it will preserve other environment variables, e.g. `$SSH_AUTH_SOCK`. – cypheon Jun 05 '14 at 08:54
  • 2
    This fixed the issue for me in the cleanest way so far. Thanks a lot! – meghaphone Jun 06 '14 at 21:20
  • 2
    This fixs git. But whenever I need to use ssh with my id_rsa.pub, I was asked to enter the passphrase. I didn't have to do this before change initial command, nor in Terminal.app. Any idea? – ZeR0 Jun 07 '14 at 16:40
  • wow. i cant believe 10.10 borks this so badly. thanks for the solution. I was scratching my head for a whole day – Drew Jun 08 '14 at 01:38
  • 5
    I think ```/bin/bash -c /bin/zsh``` is better than ```/usr/bin/login -f ```, because it keeps the character encoding. ```/usr/bin/login -f ``` lost my encoding and I cannot display my files as normal. – Alpha Liu Jun 10 '14 at 15:10
  • I don't know how to change the "initial command in your iTerm session"? Do you mean in the .zshrc? – Marcosc Jun 10 '14 at 20:50
  • @ZeR0, I had the same issue. Alpha Liu's solution above solves both problems (git and the ssh agent). – cassianoleal Jun 11 '14 at 16:31
  • +1 Thanks! You saved me from this git-issue and a ton of other brew-issues! – Paaske Jun 26 '14 at 10:17
  • @cypheon thanks, I agree with @AlphaLiu that `/bin/bash -c /bin/zsh` is better. EDIT: actually, just updating to the 20140629 iTerm2 release is the best fix. – mculp Oct 20 '14 at 14:52
  • @pilif's answer did the trick for me, thanks a lot! I added the `-l` flag to `/usr/bin/login` to keep the directory of the last session, i.e. `/usr/bin/login -lf `. – erlind Jun 05 '14 at 16:20
  • Upgrading to iTerm Build `2.0.0.20141103` solved the problem for me. – srt32 Dec 16 '14 at 05:32
35

I believe this is a bug in iTerm when using zsh. They deliberately don't invoke /usr/bin/login, and they don't use execle to clear the environment variables like they should be.

Jeremy Huddleston Sequoia
  • 22,938
  • 5
  • 78
  • 86
  • 1
    Wow I think you're right. I have spent hours trying to get various Git fixes to work, and it turns out switching from iTerm2 w/ zsh to Yosemite's default Terminal (still with zsh) works great. How did you find this? – jbnunn Jun 05 '14 at 00:59
  • 8
    Well, this is the most specific group of people ever... What an edge case. – Drew Jun 05 '14 at 02:35
  • yeah. i feel you! the env PATH is different from default terminal – alexzg Jun 05 '14 at 03:10
  • 2
    that was a very good analysis. So a good workaround is to set the initial command in iTerm to /usr/bin/login -f . – pilif Jun 05 '14 at 04:10
  • 13
    Another workaround is setting the login shell command in iTerm to `/bin/bash -c /bin/zsh` – Vince Jun 05 '14 at 14:05
  • A bug report has been filed for iTerm2 (whether not it's an iTerm2 bug) [right here](https://code.google.com/p/iterm2/issues/detail?id=3048&sort=-id). If there indeed is an issue with OS X 10.10 and not iTerm2, then it's probably a good idea for us to use [this fix](http://stackoverflow.com/a/24051529/194869) and let iTerm2 weather out the ever-changing-and-fixing-Developer-Preview storm. – Ben Kreeger Jun 05 '14 at 17:07
  • 1
    Changing from `login shell` to `command` in the Preferences > Profile > General section, and using `/bin/bash -c /bin/zah` as @Sorenly has suggested, fixed this right up! – jlmakes Oct 18 '14 at 10:12
  • typo @JulianLloyd: `/bin/bash -c /bin/zsh` not `/bin/bash -c /bin/zah` – dylanjha Oct 31 '14 at 17:44
20

Downloading the newest version of iTerm2 fixed this for me!

Marthyn Olthof
  • 1,029
  • 11
  • 22
  • 1
    If you want to solve it without proving that you are a techie..., just do this. Thanks to Marthyn... – Krishna Prasad Varma Oct 22 '14 at 04:19
  • As the comments below said, it appears to be iTerm and zsh together that prevents git pulls from working. Going to iTerm2 fixes it. – MikeHoss Nov 12 '14 at 16:15
  • 4
    To clarify @MikeHoss, iTerm2 version 1.0.x doesn't work, but iTerm2 version 2.0.x does. Both are iTerm2, but the version is what matters. – Kevin Cooper Nov 19 '14 at 23:07
16

Another solution, modify your iTerm2

cd /Applications/iTerm.app/Contents/MacOS
mv iTerm iTerm-bin

cat > iTerm <<EOF
#!/bin/sh
unset PATH
\${0}-bin
EOF

chmod +x iTerm

Done.

Enjoy your iTerm2 with Yosemite!

Feng
  • 3,592
  • 2
  • 15
  • 14
13

As a temp solution I modified git-pull lines 11, 12, and 336 to be:

. /usr/local/Cellar/git/2.0.0/libexec/git-core/git-sh-setup

. /usr/local/Cellar/git/2.0.0/libexec/git-core/git-sh-i18n

eval="/usr/local/Cellar/git/2.0.0/libexec/git-core/git-merge $diffstat $no_commit $verify_signatures $edit $squash $no_ff $ff_only"

This fixes git-pull for now, but I'm sure there is a better solution.

Ubiquill
  • 156
  • 5
  • 2
    I also had to change like 231 to `. /usr/local/Cellar/git/2.0.0/libexec/git-core/git-parse-remote` – Keith Smiley Jun 03 '14 at 20:51
  • 2
    In case I needed to change this, I set up mine to point to `$GIT_PATH/git-sh-setup`, etc. – TheJF Jun 03 '14 at 21:05
  • 1
    I'm getting `/usr/local/Cellar/git/2.0.0/libexec/git-core/git-sh-setup: line 334: git: command not found fatal: 'pull' appears to be a git command, but we were not able to execute it. Maybe git-pull is broken?` After applying this fix, anyone have an idea what to do? – Drew Jun 04 '14 at 04:08
  • @Andrew This is ugly but I had to go through git-sh-setup and replace all `git` with `/usr/local/bin/git`. There were a few instances of `git` in git-pull also that had to be replaced – jbnunn Jun 04 '14 at 17:37
3

Here's a temporary fix (assuming Homebrew and Git 2.0.0) if you need Git to work before an official fix comes out. I setup two shell variables:

export GIT_PATH="/usr/local/Cellar/git/2.0.0/bin"
export GIT_CORE_PATH="/usr/local/Cellar/git/2.0.0/libexec/git-core"

... and then replaced instances of git with appropriate absolute links. You can use the following Gists to do the same:

  • Replace /usr/local/Cellar/git/2.0.0/libexec/git-core/git-sh-setup/ with git-sh-setup
  • Replace /usr/local/Cellar/git/2.0.0/libexec/git-core/git-stash/ with git-stash
  • Replace /usr/local/Cellar/git/2.0.0/libexec/git-core/git-pull/ with git-pull

This is a hack for sure, but it will get you going.

EDIT: Make sure you look at the answer from @pilif before doing this...

jbnunn
  • 6,161
  • 4
  • 40
  • 65
1

Ubiquill's workaround applies for git rebase (and presumably whichever other functions don't work) as well. In that case, it requires replacing lines 47 and 48 with the following *:

. /usr/local/Cellar/git/2.0.0/libexec/git-core/git-sh-setup
. /usr/local/Cellar/git/2.0.0/libexec/git-core/git-sh-i18n

* This path assumes that you have git installed with homebrew, and it lives inside of /usr/local/Cellar/git/2.0.0/.

ferchak
  • 11
  • 2
1

Edit your git-pull file and add this line on top of it (just after the comment block)

PATH="$(dirname $0):$PATH"

Or just copy paste this in your terminal :

ed -s $(which git-pull) <<< $'6i\nPATH="$(dirname $0):$PATH"\n.\nwq'

Update: As presumed by pilif, since last iTerm2 update (1.0.0.20140629), git-pull run properly without this PATH override.

Community
  • 1
  • 1
pyrou
  • 351
  • 1
  • 8
  • This seems to be the only solution to go one step forward in my configuration. After adding the PATH line, I get this error when I try to PULL: git: 'credential-osxkeychain' is not a git command. See 'git --help'. Any ideas? – kiks73 Nov 05 '14 at 15:15
1

There is an update to git-rebase.sh

https://github.com/git/git/pull/110/files

basbebe
  • 567
  • 1
  • 9
  • 25
0

UPDATE: still not working with release mentioned below, my mistake. Git push works Git pull doesn't.

It seems to me that the issue has been fixed by Apple with Mac OS X Yosemite 10.10 (14A329r). i am on the general Beta Yosemite channel (not developer). Git push/pull works as expected again without any modifications.

Frank Lämmer
  • 2,165
  • 19
  • 26