Re: [PATCH] Gitweb: Avoid warnings when a repo does not have a valid HEAD
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Dec 16, 2011, 14:55 UTC
- Message-ID
- <201112161555.37472.jnareb@gmail.com>
- In-Reply-To
- <7vty51lbb0.fsf@alter.siamese.dyndns.org>
On Thu, 15 Dec 2011, Junio C Hamano wrote:
Show 15 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
>> Joe Ratterman <jratt0@gmail.com> writes:
>>
>>> It is possible that the HEAD reference does not point to an existing
>>> branch. When viewing such a repository in gitweb, a message like this
>>> one was sent to the error log:
>>>
>>> gitweb.cgi: Use of uninitialized value in string eq at /usr/src/git/gitweb/gitweb.cgi line 5115.
>>>
>> ..., but in that case a repository with
>> a HEAD that points at an unborn branch _and_ have other refs that do point
>> at existing commit is already screwed-up, so if we want to be extremely
>> pedantic then perhaps ...
>>
>> my $curr = ((defined $head && exists $ref{"id"} && defined $ref{"id"}) my $curr = ((defined $head && defined $ref{"id"})is enough, because '!exists $hash{key}' implies '!defined $hash{key}' (though reverse is not true).
Show 10 quoted lines
>> ? ($ref{"id"} eq $head)
>> : 0);
>
> Just in case, I was not suggesting to update the patch to look like the
> above by "if we want to be extremely pedantic".
>
> After all, that error message in the log may be a good thing that notifies
> the site administrators about a suspicious repository so that it can be
> fixed (even though it was not a designed "feature" but something that
> happens to work).Well, but for that those error messages should describe error; the above is quite hard to translate to
warning: HEAD points to an unborn branch in repository foo.git
BTW. we should probably warn about this situation more clear, perhaps by showing warning instead of empty place where subject of current commit is usually shown.
Anyway git marks up branches (sic!) that _point to_ the same commit as HEAD because we calculate it anyway, at least for 'summary' view.
Better solution would be to examine HEAD (either using Perl, or using "git symbolic-ref") to get _name_ of current branch. I'd rather avoid yet another command call.
-- Jakub Narebski Poland