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

Jakub Narebski [off-list ref] writes:

On Fri, 17 Feb 2012, Junio C Hamano wrote:
 

quoted

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*.