Jakub Narebski <jnareb@xxxxxxxxx> 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"
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
