Re: [PATCHv2 1/3] gitweb: Deal with HEAD pointing to unborn branch in "heads" view

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 17, 2012, 14:28 UTC
Message-ID: <7vipj5v8jh.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201202171441.35618.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

Show 15 quoted lines

> On Fri, 17 Feb 2012, Junio C Hamano wrote:
>  
>> But after trying to write a reroll myself, I have to wonder what would
>> happen if you have two branches pointing at the same commit as the one at
>> HEAD.  Why isn't the use of current_head class controlled by comparison
>> between the name of the ref and the output from "symbolic-ref HEAD"?
>
> If there is more than one branch that points to HEAD commit, they all
> will be highlighted.
>
> Using "git symbolic-ref HEAD", or just reading '.git/HEAD' file or symlink
> is on my todo list.  This will make gitweb highlight current branch
> correctly even if there is more than one branch that point to the same
> HEAD commit, and make it possible to support "detached HEAD" (which I think
> is not supported at all now).

You should be more honest and admit that showing unrelated branches that happen to point at the same commit as the current HEAD does (this includes the case where HEAD is detached) as if they are *ALL* current branch is *NEITER* working *CORRECTLY* nor *SUPPORT*ing "detached HEAD" at all. It may not be giving a runtime error, but instead it is showing AN INCORRECT RESULT.

I'd grant you that this is not a new problem this patch introduces, and it may not even be a bug you introduced long time ago. The patch gives the same INCORRECT RESULT as it intended to do before the patch, and removes one runtime error, so it is not worsening the situation, but that does not change the fact that the code after the patch is still *WRONG*.