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