I was trying to set up some git aliases by adding these lines to my ~/.gitconfig
file:
[alias]
st = status
ci = commit
br = branch
And when I go to run these commands in the terminal: git st
, I get the following error fatal: cannot exec 'git-st': Not a directory
. I do not know what the problem is and I have looked online and cannot find why it is doing this. I am running Mac OS 10.6.4 using Git 1.7.1. Somebody please help me out. If I don't figure out why it is doing this, I'll go crazy! Thanks!
Git aliases are a powerful workflow tool that create shortcuts to frequently used Git commands. Using Git aliases will make you a faster and more efficient developer. Aliases can be used to wrap a sequence of Git commands into new faux Git command.
Your git aliases are often stored per your user's configuration at ~/. gitconfig . You can also manually set aliases using, for example, the command git config alias. s 'status -s' .
unutbu correctly pointed out to the git-osx-installer issue 53, which states:
Basically, I had
/root/bin
in my path and didn't have permissions for that directory.Interestingly, this was not a problem with git 1.6.3, but it was with 1.7.0 and 1.7.1.
A strace -f -eexecve git st 2>&1 | grep EACC
can help see what directory is the problem:
[pid 6469] execve("/usr/games/bin/git-st", ["git-st"], [/* 72 vars */]) = -1 EACCES
(in this instance, the /usr/games/bin/
)
Another way to find the path with the problem is:
echo $PATH |tr ':' '\n' |xargs ls -ld
One of my invalid items is actually an NFS mounted directory that I don't have permission to access because I have not authenticated via Kerberos to the corporate NFS server.
Removing that one item from thePATH
fixes the issue, and 'git stat
' (my alias for status) now works.
PeterT mentions in the comment that you might not have strace
available (like in Solaris or OsX, as detailed in "Equivalent of strace -feopen < command >
on mac os X"), in which case dtruss
is a good equivalent.
dtruss -f -t execve git st 2>&1 | grep EACC
I had this problem too but with a subtly different cause:
In my case the path contained an entry that was a file rather than a directory. The permissions on the file itself and its directory were fine. When a new terminal was loaded the file could be run from anywhere. However, git gave an identical error message.
So as well as looking for folders on the path with incorrect permissions I suggest anyone else with this problem also checks that the path points only to folders and not to files.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With