Dnia niedziela 9. listopada 2008 00:27, Francis Galiegue napisał:
quoted text
> Le Saturday 08 November 2008 23:35:48 Jakub Narebski, vous avez écrit :

quoted text
>>> 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?

Not necessary. Please remember that you can configure gitweb to either
use _alternate_ stylesheet (instead of provided gitweb.css), or use
_additional_ stylesheet (for example gitweb-commit.css in addition to
gitweb.css)
 
quoted text
>>> 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.

I'm sorry about that. Perhaps I should use only one mechanism.
 
quoted text
> What I understand is that right now, the SHA1 links are "pre-processed" by 
> gitweb so that the 'a' parameter is correct, right?

No, they are 'post-processed': finding correct action is left to
_after_ you click on the link (it is more natural, and helps
performance).

If you don't know action for given SHA-1 you can use either

  http://example.com/gitweb.cgi?a=object;h=deadbeef

which finds correct type (for example 'commit') and redirects using
HTTP 302 Found redirection to

  http://example.com/gitweb.cgi?a=commit;h=deadbeef

This way is used bu SHA-1 committag in commit messages.


Alternate solution (meant for bugtrackers), done by another author,
is to simply skip action ('a') parameter:

  http://example.com/gitweb.cgi?h=deadbeef

and then gitweb finds type of object and act accordingly (without
redirect to correct view).

[...]
quoted text
>>> 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? 

Errr... I don't understand.

The examples perhaps are not the best. One would be for example to use
different class (different style) for Signed-off-by signoff (which
denotes signing Certificate of Origin), and the rest of (informative)
signoff:

  [gitweb]
  	committags = sha1 signoff_signed signoff

Another example would be to add SPAM-protection of emails, for example
replacing 'user@example.com' by 'user AT example DOT com', or something
more advanced. This have to be used _after_ signoff, because otherwise
regexp could have difficulties matching mangled email

  [gitweb]
  	committags = sha1 signoff mailto

quoted text
>>
>>> 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?

For example signoff line

  Signed-off-by: A U Thor <author@example.com>

would be replaced by

  {<span class="signoff">}Signed-off-by: A U Thor <author@example.com>{</a>}
 
where parts inside {...} is HTML code, and should be not expanded
further, and parts outside it could be expanded further by following
lower priority committags (like anti-SPAM for emails), and have to be
finally HTML escaped (like '<' and '>' in email in signoff).


.....................................................................

quoted text
> [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]

First, having gitweb in (almost) one piece makes for easier installation.
But there are plans to have gitweb use Git.pm or future Got::Repo and
friends. I'm not sure about further splitting...

Second, we cannot in good faith use CPAN modules which cannot be found
in standard Perl distributions, or at least in some trusted extras
package (application) repositories, as gitweb is sometimes run on
machines with tight security (think kernel.org for example) where you
cannot simply ask admin to install some third-party alpha-version CPAN
module.

-- 
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html