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

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

quoted

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.

quoted

quoted

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?

quoted

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

quoted

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? 

quoted

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