Re: error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied

From: Jeff King <peff@peff.net>
Date: Apr 29, 2009, 03:29 UTC
Message-ID: <20090429032943.GB8826@coredump.intra.peff.net>
In-Reply-To: <20090428073138.GA9094@elte.hu>

On Tue, Apr 28, 2009 at 09:31:38AM +0200, Ingo Molnar wrote:

Show 16 quoted lines

>  aldebaran:~/git> git pull
>  error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied
>  From e2:git
>   ! 66996ec..95110d7  master     -> origin/master  (unable to update local ref)
>   * [new tag]         v1.6.3-rc2 -> v1.6.3-rc2
>  error: some local refs could not be updated; try running
>   'git remote prune origin' to remove any old, conflicting branches
> 
> Obviousy Git cannot update the ref there so the failure is OK, but 
> the git-remote advice it gives is confusing IMHO: the 'git remote 
> prune origin' cannot fix anything. (and it is clear from the fetch 
> permission failure that there's no chance to fix anything here.)
> 
> I suspect there are other, more typical failure modes where that 
> advice is useful - just wanted to point out that it's confusing 
> here.

Yeah, I knew that when I wrote it:

  $ git log -1 --format=%s%n%b f3cb169
  fetch: give a hint to the user when local refs fail to update
  There are basically two categories of update failures for
  local refs:

    1. problems outside of git, like disk full, bad
       permissions, etc.

    2. D/F conflicts on tracking branch ref names

  In either case, there should already have been an error
  message. In case '1', hopefully enough information has
  already been given that the user can fix it. In the case of
  '2', we can hint that the user can clean up their tracking
  branch area by using 'git remote prune'.

  Note that we don't actually know _which_ case we have, so
  the user will receive the hint in case 1, as well. In this
  case the suggestion won't do any good, but hopefully the
  user is smart enough to figure out that it's just a hint.

Note the repeated use of "hopefully". :) Maybe the earlier message is too hidden to rely on. We might be able to get by with checking "errno" for ENOTDIR after trying to lock the ref and using a different message, but I don't know how portable that will be.

-Peff