# aliases causing “Permission denied” error in git v1.7

3 messages from 2011-11-04 to 2011-11-05. Participants: Алексей Данченков, Jeff King.
Thread: https://gitlist.dev/t/28838

## Алексей Данченков, 2011-11-04 08:09

Subject: aliases causing “Permission denied” error in git v1.7
Message-ID: <CALUFZ3n9cpHw3r3rcGriDqvJ+UM83L3Q19m=0YeAy51LBJzosA@mail.gmail.com>
URL: https://gitlist.dev/e/CALUFZ3n9cpHw3r3rcGriDqvJ%2BUM83L3Q19m%3D0YeAy51LBJzosA%40mail.gmail.com

```
Hi!

$ git co -b newbranch
$ git co oldbranch

results in "fatal: cannot exec 'git-co': Permission denied" error.

In the same time, things like

$ git checkout -b newbranch
$ git checkout oldbranch

and

$ sudo git co -b newbranch
$ sudo git co oldbranch

work as expected. Ownership rights for the .git die are set for the user
and 0755/0644 are the mode for .git dir/subdir/files. There are no git-co
script anywhere in the system (as it is an alias to git-checkout, which
resides in /usr/libexec/git-core).

Aliases are defined in .gitconfig of the home dir:

[alias]
co = checkout

There is no difference in git config for root or normal user.

Things work well as expected when I install git v1.6. Going back to 1.7
gives me the same error.

What am I missing?

---

Gentoo / kernel v3.0.6 / git v1.7.3.4

```

## Jeff King, 2011-11-04 20:34

Subject: Re: aliases causing “Permission denied” error in git v1.7
Message-ID: <20111104203415.GB26591@sigill.intra.peff.net>
URL: https://gitlist.dev/e/20111104203415.GB26591%40sigill.intra.peff.net
In-Reply-To: <CALUFZ3n9cpHw3r3rcGriDqvJ+UM83L3Q19m=0YeAy51LBJzosA@mail.gmail.com>

```
On Fri, Nov 04, 2011 at 12:09:07PM +0400, Алексей Данченков wrote:

> $ git co -b newbranch
> $ git co oldbranch
> 
> results in "fatal: cannot exec 'git-co': Permission denied" error.

Git will try commands in your PATH before aliases. So you are running
into a permissions problem with a "git-co" in your PATH.

Or more likely, there is an inaccessible directory of your PATH (and we
get the same error code from execve whether it is the directory or the
file itself which lacks permission). Try "git foobar" and I suspect you
will see the same thing (it doesn't matter that you have no foobar
alias; we never get past the "try to exec it" stage).

If you are on Linux, try:

  strace -f -e execve git foobar

to see the the problematic entry that is returning EACCES. Or look
through your $PATH manually.

-Peff

```

## Алексей Данченков, 2011-11-05 11:51

Subject: Re: aliases causing “Permission denied” error in git v1.7
Message-ID: <CALUFZ3mgR8aRGO2yCfxKvHXqmz4ZOXBNSPuq0Q69yZ7ys5ttzQ@mail.gmail.com>
URL: https://gitlist.dev/e/CALUFZ3mgR8aRGO2yCfxKvHXqmz4ZOXBNSPuq0Q69yZ7ys5ttzQ%40mail.gmail.com
In-Reply-To: <7vhb2jbopp.fsf@alter.siamese.dyndns.org>

```
Thank you very much, Jeff and Junio!

Not only I discovered more than one directory mentioned in the $PATH,
but missing, but also learned a lot, including the strace tool.

Cheers, Alexei

2011/11/5 Junio C Hamano <gitster@pobox.com>:
> Jeff King <peff@peff.net> writes:
>
> I do not know why my response is not showing up in the list archive, but
> the complaint was that "git co" works for him and "sudo git co" does not.
>
> I suspect that Alexsey will see differences between these:
>
>    $ sh -c 'echo $PATH $HOME'
>    $ sudo sh -c 'echo $PATH $HOME'
>
> Most likely, the latter would say /root/bin and /root; if an element in
> the $PATH is unreadable, git would say "cannot exec 'git-co': Permission denied".
>
>
>

```