14

I recently upgraded my MacBook Pro to Snow Leopard and "git pull" returns:

rakudo $ git pull
git: 'pull' is not a git-command. See 'git --help'

Did you mean this?
        shell
rakudo $ git-pull
-bash: git-pull: command not found

I've tried reinstalling via macports, but to no avail. Then I saw this

rakudo $ git --exec-path
/Users/ovid/libexec/git-core

That surprised me as that directory does not exist, nor has it ever existed. Google is not helping here. Hopefully you can :)

Ovid
  • 11,580
  • 9
  • 46
  • 76
  • I ran into same problem, when I tried to hack git binary out of Xcode package. `ln -s /Applications/Xcode.app/Contents/Developer/usr/bin/git ~/bin/git` – shakthi Feb 22 '13 at 05:44

7 Answers7

24

Looking in the source of git, there's a comment in git.c:

/*
 * We use PATH to find git commands, but we prepend some higher
 * precedence paths: the "--exec-path" option, the GIT_EXEC_PATH
 * environment, and the $(gitexecdir) from the Makefile at build
 * time.
 */

If you call git --exec-path, you end up calling const char *git_exec_path(void) in exec_cmd.c. That looks like this:

const char *env;

if (argv_exec_path)
    return argv_exec_path;

env = getenv(EXEC_PATH_ENVIRONMENT);
if (env && *env) {
    return env;
}

return system_path(GIT_EXEC_PATH);

Now, _argv_exec_path_ is set when you say --exec-path=/some/where so can be discounted. You've stated that the environment variable isn't set. GIT_EXEC_PATH is defined during compilation in the Makefile. Going backwards, it seems to be defined as just libexec/git-core. So, we need to look at what system_path() does instead.

I'm not sure whether RUNTIME_PREFIX is defined for you. But while nosing in the Makefile, I did notice that prefix defaults to $(HOME). I suspect that this may be the cause of your problems.

The simple answer is to put this in ~/.bashrc:

export GIT_EXEC_PATH=/opt/local/libexec/git-core

If you want to find out more about what's going on, you'll probably have to recompile git using port -d upgrade -f git-core (or similar) and look closely at the build log to see where prefix is being set. Incidentally, port cat git-core shows heavy usage of ${prefix} so it should (hopefully) be obvious.

Dominic Mitchell
  • 11,861
  • 4
  • 29
  • 30
  • 3
    Just a clarification for anyone else who finds this: the path to git's commands is indeed set at compile time (though it can be modified by GIT_EXEC_PATH, and then by --exec-path). This is most likely set at compile time by `make prefix=/path/to/git ...`. Hopefully any pre-built versions will properly do this! – Cascabel Sep 23 '09 at 14:24
  • Thanks for the answer. Perhaps of note: Adding the export statement to ~/.profile (which exists by default in my Snow Leopard install, neither .bashrc nor .bash_profile do) also works. – Rob Drimmie Jun 17 '10 at 00:52
  • I had this same problem, but on my web host. The general solution seems to be, find wherever your /libexec/git-core is, and then set GIT_EXEC_PATH to that path as described here. In my case it was in $HOME/git/src/libexec/git-core – mindthief Dec 06 '10 at 07:13
  • I've got two virtually identical RedHat servers, both with git 1.7.6 compiled from source. On one, git pull works fine, on the other I get the error above. Have tried chmod a+rx /usr/local/libexec and have tried export GIT_EXEC_PATH=/usr/local/libexec/git-core in both the user's .bashrc and .bash_profile. It does work for root, but not for user accounts. Baffled. Suggestions? I'd even be happy to recompile the source if there was a magic flag to give it. – shacker Aug 31 '11 at 23:33
  • 1
    I was finally able to fix this by installing git via yum rather than compiling. Weird. – shacker Aug 31 '11 at 23:57
2

Interesting. try echo $GIT_EXEC_PATH, which git. It's unlikely to be related to the snow beast…

Michael Krelin - hacker
  • 138,757
  • 24
  • 193
  • 173
2

On my system, libexec/git-core is in /usr/local and not /opt/local. The /usr/local/libexec directory had only root accessible permissions for me, and this fixed the problem:

sudo chmod a+rx /usr/local/libexec
sth
  • 222,467
  • 53
  • 283
  • 367
Bo Morgan
  • 21
  • 1
  • That one worked for me too. I had installed (configure, make, sudo make install) on Mac OS X, and apparently it put the wrong permissions there. – danwood Jul 21 '10 at 14:50
1

Have you tried the steps on the ports Migration wiki page? It was painful, but after doing the --force uninstall and reinstall process, I haven't had any issues with any of my ports, which includes git (with pretty much every variant turned on).

Hank Gay
  • 70,339
  • 36
  • 160
  • 222
  • Yeah, did that a couple of days ago after I found so many of my ports not working. It was, as you mention, painful. It also didn't solve my git problem :) – Ovid Sep 23 '09 at 12:30
0

Git compiles so easily there's really not any reason to bother with any of macports' craziness. Get rid of whatever's in /opt and try building it the normal way. Odds are good it will work.

Azeem.Butt
  • 5,855
  • 1
  • 26
  • 22
0

Another option is to download from the helpful page on GitHub:

http://help.github.com/mac-git-installation/

They have a stand-alone installer (though the second option there is MacPorts...)

They used to have a very nice all in one page tutorial that seems to be splintered now. What a shame.

Kendall Helmstetter Gelner
  • 74,769
  • 26
  • 128
  • 150
0

For me, this was an issue only specifically relevant to my brew install. On OSX 10.9.2, I had brew installed under root, so this works for me:

sudo su
export GIT_EXEC_PATH=/Applications/Xcode.app/Contents/Developer/usr/libexec/git-core
brew update # or whatever you want from here
Geremy
  • 2,415
  • 1
  • 23
  • 27