Re: gitweb: cloud tags feature produces malformed XML for errors

[Jakub Narebski <jnareb@gmail.com>]

On Wed, 2 Mar 2011 02:06, J.H. wrote:

> As a general note the cloud tags code that's there has a whole slew of
> problems, including a pretty trivial way to crash gitweb entirely if the
> tags file is malformed in any way to what it's expecting.

That's not a huge problem, I think; it would be enough to add some
validation to parsing ctags code (e.g. treat any contents that is
not a single number as a 1).
 
> I've said it before, I'd rather see that code reverted or completely
> overhauled, and as far as I know repo.or.cz is the only place even using
> the code at all.
> 
> I also think I reported this particular error a couple of years ago
> (with the file being malformed and causing all kinds of problems).  The
> fact that the tags don't follow the repository when it's cloned more or
> less makes this entire feature a giant PITA, couple that with no good
> documentation on how to create the tag files (I think the file itself
> needs to have filename of tag, and *ONLY* contain 1 for it's contains
> for it to work)
> 
> Linux:
> 1
> EOF

Well, neither does README.html follow the repository when it is cloned,
and usually neither does description ('description' file is generated by
git default template, and description file overrides `gitweb.description'
config variable).

Documentation always can be added, either as comments for the 'ctags'
feature, or in gitweb/README (or, in the future, in gitweb manpage).


What is most important that makes this feature to be considered for
removal (or rehauling) is that only half of this feature is implemented
in gitweb: the displaying part.  There is half-attempt of providing
some web interface for managing tags... which needs external script with
strict coupling, doesn't offer any access control as far as I know, do
not allow deleting tags, etc.

-- 
Jakub Narebski
Poland