Re: [RFC] Configuring (future) committags support in gitweb

[Francis Galiegue <fg@one2team.net>]

Le Saturday 08 November 2008 23:35:48 Jakub Narebski, vous avez écrit :

> >
> > What do you mean with "not having to write whole replacement rule"?
>
> Like in example with 'link' rule, not having to write whole
> <a href="http://example.com/bugzilla.php?id=$1">$&</a>
> (or something like that).
>

OK, good one.

> >> I think it would be good idea to use repository config file for
> >> setting-up repository-specific committags, and use whatever Perl
> >> structure for global configuration. The config language can be
> >> borrowed from "drivers" in gitattributes (`diff' and `merge' drivers).
> >>
> >> So the example configuration could look like this:
> >>
> >>   [gitweb]
> >>   	committags = sha1 signoff bugzilla
> >>
> >>   [committag "bugzilla"]
> >>   	match = "\\b(?:#?)(\\d+)\\b"
> >>   	link  = "http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1"
> >>
> >> where 'sha1' and 'signoff' are built-in committags, committags are
> >> applied in the order they are put in gitweb.committags;
> >
> > I don't understand what the "signoff" builtin is : is that a link to see
> > only commits "Signed-off-by:" a particular person?
>
> Committags doesn't need to be replaced by links. In this case I meant
> here using 'signoff' class for Signed-off-by: (and the like) lines, by
> wrapping it in '<span class="signoff">' ... '</a>'.
>

Well, this would also mean to update gitweb.css, wouldn't it?

> > And also, what about the sha1 builtin? AFAIK, a SHA1 can point to a
> > commit, a tree, and others... In fact, it points to any of these right
> > now, but how would you tell apart these different SHA1s in a commit
> > message? The only obvious use I see for it is the builtin "Revert ..."
> > commit message, that the commiter _can_ override...
>
> SHA1 (or shortened SHA1 from 8 charasters to 40 characters, or to be
> even more exact something that looks like SHA1) is replaced by link
> to 'object' view, which in turn finds type of object and _redirect_
> to proper view, be it 'commit' (most frequent), 'tag', 'blob' or 'tree'.
>
> We could have used instead gitweb link with 'h' (hash) parameter, but
> without 'a' (action) parameter, which currently finds type of object
> and _uses_ correct view...
>

OK, you lost me somewhat.

What I understand is that right now, the SHA1 links are "pre-processed" by 
gitweb so that the 'a' parameter is correct, right?

Out of curiosity, I just went to the kernel git repository (I don't know the 
git version that git.kernel.org uses offhand) and altered the 'a' parameter 
to something which is not even an 'a' command at all: 500...

However, if I try a VALID 'a' command with an "irrelevant" 'h' parameter, it 
acts quite funny: it just looks like it wants to try the closest match, but 
takes some time figuring it out... Sometimes to something relevant, sometimes 
to nothing really relevant. See for instance [1], in which 'a' was 
originally "commit".

Ow.

 [1]
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=tag;h=788a5f3f70e2a9c46020bdd3a195f2a866441c5d

> > Finally, is there any reason to think that a sha1 or signoff committag
> > will ever need to be overriden in some way?
>
> One might not want to link SHA1, for example if there are lots of false
> positives because of commit message conventions or something, or refine
> 'signoff' committag to use different styles for different types of
> signoff: Signed-off-by, Acked-by, Tested-by, other.  Having explicit
> 'signoff' committag allows us also to put some committags _after_ it,
> for example SPAM-protection of emails, or add some committag before
> 'sha1' to filter out some SHA1 match false positives.
>

Hmmm, so this means you'd want to make styles customizable somewhat (signoff). 
In fact, what you really want is span for CSS! Then why not, just, making a 
document to say "This is what you can do with CSS for gitweb", and say "these 
are the available CSS tags", and then be done with it?

I mean, when comes the day that someone will WANT other spans to be defined, 
badly, it's not like it will be unheard of, won't it? 

>
> > And I don't see what you '_a_' and '_b_' are about...
>
> For example in link match, the text of the link can be further refined
> by committags later in sequence.

I still don't get it. Can you give an example?

[personal thoughts: it would be really, really nice if, somewhat, gitweb.perl 
were splitted somewhat into different modules, and ideally use more 
of "what's out there on CPAN". I'm convinced that some CPAN modules would be 
of GREAT help to gitweb, as well as I'm convinced that not many people out 
there use Windows to run gitweb anyway :p]

-- 
fge