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

[Junio C Hamano <gitster@pobox.com>]

Jakub Narebski <jnareb@gmail.com> writes:

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

Ok, I'll queue the first one (disambiguate) for 1.5.4 while letting the
people decide the latter for now.

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

You are getting the layering all wrong.

 * git-cat-file takes "object name" on its command line (so do many
   other commands).

 * One of the way to spell an "object name" is to refer to it with a ref
   that can reach it (e.g. to name 12th generation parent of the tip of
   the master branch, you spell "master~12" and you are using the ref
   refs/heads/master).

 * You do not have to always write out the ref in full.  There is a
   defined order to disambiguate refs (see git-rev-parse(1)), that
   allows you to say 'master' and it expands to either refs/tags/master,
   refs/heads/master or whatever.

Now git-cat-file does not care how you spelled your object name, and has
no business influencing the ref disambiguation order.  You _could_ argue
"git cat-file tag <foo>" _expects_ <foo> to name a tag, but that logic
is very flawed (and that is why I said your understanding of layering is
screwed) for two reasons:

 (1) <foo> may be user input to the script that uses cat-file and the
     script may be expecting a tag there.  Perhaps the script is about
     creating a new branch from a tag (expecting a tag) and adds some
     administrative info in the configuration file for the branch.  It
     does first:

	t=$(git cat-file tag "$1") || die not a tag

     and later the script may want to do:

	git branch $newone "$1"
        git config branch.$newone.description "created from tag $1 ($t)"

     If you make "cat-file tag" to favor tag, and in a similar fashion
     if you make "branch" favor branch, the above will not do what you
     expect.

     Consistently resolving the refname without (or minimum number of)
     exceptions would give less surprising result.

 (2) "git cat-file -t <foo>" is to find out what type the object is and
     is meant to be used by callers who do not know the type.  There is
     no "favoring this class of ref over other classses" possible there.

> 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)?

Huh?  Wouldn't something like this be enough?

	>expect.empty &&
	cmd >actual.out 2>actual.err &&
        diff -u expect.empty actual.err &&
        first=$(sed -e '1q' <actual.out) &&
	test "z$first" = "I like it"