On Tue, Apr 28, 2009 at 09:31:38AM +0200, Ingo Molnar wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html