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

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Francis Galiegue <fg@...>
Cc: <git@...>
Date: Saturday, November 8, 2008 - 8:25 pm

Dnia niedziela 9. listopada 2008 00:27, Francis Galiegue napisał:


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)
 

I'm sorry about that. Perhaps I should use only one mechanism.
 

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

[...]

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


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


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


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
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC] Configuring (future) committags support in gitweb, Jakub Narebski, (Sat Nov 8, 3:07 pm)
Re: [RFC] Configuring (future) committags support in gitweb, Francis Galiegue, (Sat Nov 8, 4:02 pm)
Addresses with full names in patch emails, Marcel M. Cary, (Tue Feb 24, 11:38 am)
Re: Addresses with full names in patch emails, Jakub Narebski, (Tue Feb 24, 11:58 am)
Re: [RFC] Configuring (future) committags support in gitweb, Francis Galiegue, (Sat Nov 8, 7:27 pm)
Re: [RFC] Configuring (future) committags support in gitweb, Jakub Narebski, (Sat Nov 8, 8:25 pm)