Re: print errors from git-update-ref

From: Junio C Hamano <junkio@cox.net>
Date: Jul 24, 2006, 06:06 UTC
Message-ID: <7vk663h6zi.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <81b0412b0607180613t603551b8t865b407c40ab8aef@mail.gmail.com>

"Alex Riesen" <raa.lkml@gmail.com> writes:

Show 11 quoted lines

> ...otherwise it not clear what happened when update-ref fails.
>
> E.g., git checkout -b a/b/c HEAD would print nothing if refs/heads/a
> exists and is a directory (it does return 1, so scripts checking for
> return code should be ok).
>
> I'm attaching two patches, because I'm not quite sure where it should
> be done: git-checkout is the least intrusive, but only builtin-update-ref.c
> has enough info to help user to resolve the problem (errno is ENOTDIR,
> which is selfexplanatory). And I happen to use git-update-ref directly
> sometimes.

My gut feeling is that complaining from update-ref is fine, but I am still tired after a long week and not thinking straight, so I will not be applying this tonight.

git-applypatch, git-am, and git-branch would be helped by update-ref complaining.

Porcelains?

BTW, I wonder what happens when .git/logs/refs/a is a directory (by mistake or malice), .git/refs/a does not exist, and the user does "git checkout -b a/b/c HEAD". Or when .git/logs/refs/a/b/c does exist but is not writable. My preference is just warn but do not interrupt the primary operation, since ref-log is just an optional part of the system, but that would probably lead to confusion, so we might be better off erroring the caller out in such a case. Opinions?

git-resolve does not check exit value from update-ref, which is *BAD*, but we should be deprecating it anyway.

git-reset has the same problem of not checking the exit status from update ref. Worse yet, it calls update-ref with wrong parameter ($@ in its parameter should be $*).

Patches to fix these two and half problems should be trivial but I won't be doing that myself tonight.