Re: [PATCH] gitweb: Try harder in parse_tag; perhaps it was given ambiguous name

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 5, 2007, 10:13 UTC
Message-ID: <200712051113.40654.jnareb@gmail.com>
In-Reply-To: <7v3auh1v75.fsf@gitster.siamese.dyndns.org>

On Wed, 5 Dec 2007, Junio C Hamano wrote:

> I have these two patches still in my mailbox, unapplied:
> 
> [PATCH] gitweb: disambiguate heads and tags withs the same name
> [PATCH] gitweb: Try harder in parse_tag; perhaps it was given ambiguous name

Actually second should be [PATCH/RFC] as it penalizes the "not found" case (extra check 'if really not found').

First patch, which is modified version of Guillaume Seguin patch solves problem that links in gitweb does lead to correct 'tag' view, while the second one solves the problem from the other side: instead of ensuring that links in gitweb are unambiguous it tries to resolve ambiguity.

The problem is caused by the fact that git _always_ prefer heads (head
refs) to tags (tag refs), even when it is clear
  $ git cat-file tags ambiguous-ref
that we want a tag. So alternate solution would be to correct
git-cat-file.

Show 7 quoted lines

> I am wondering if they should be part of 1.5.4.  They look Ok but it is
> not very easy to pick up what the real breakage it is trying to fix from
> Perl gibberish.
> 
> Can we have tests (not just "we do not spit out anything to stderr") for
> gitweb so that each patch can demonstrate the existing breakage, to make
> judging easier?

True, current way of testing gitweb does not allow for test which would detect breakage noticed by Guillaume.

It would be quite easy I think to add checking if gitweb returns expected HTTP return code (HTTP status). So what is the portable way to check if first line of some output matches given regexp (given fixed string)?

-- 
Jakub Narebski
Poland