git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jakub Narebski <jnareb@gmail.com>
Date
Nov 9, 2008, 00:25 UTC
Message-ID
<200811090125.12625.jnareb@gmail.com>
In-Reply-To
<200811090027.14343.fg@one2team.net>
Dnia niedziela 9. listopada 2008 00:27, Francis Galiegue napisał:
> Le Saturday 08 November 2008 23:35:48 Jakub Narebski, vous avez écrit :
Show 8 quoted lines
>>> 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)
 
Show 16 quoted lines
>>> 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.
 
> 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).

[...]
Show 18 quoted lines
>>> 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
Show 7 quoted lines
>>
>>> 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).
.....................................................................
Show 5 quoted lines
> [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
Previous: Francis GaliegueNext: Marcel M. Cary
Message 5 of 20 in “[RFC] Configuring (future) committags support in gitweb”
  1. Jakub NarebskiNov 8, 2008
  2. Francis GaliegueNov 8, 2008
  3. Jakub NarebskiNov 8, 2008
  4. Francis GaliegueNov 8, 2008
  5. Jakub NarebskiNov 9, 2008
  6. Marcel M. CaryFeb 17, 2009
  7. 1/2 gitweb: Fix warnings with override permitted but no repo overrideMarcel M. Cary, Feb 18, 2009
  8. 2/2 gitweb: Hyperlink multiple git hashes on the same commit message lineMarcel M. Cary, Feb 18, 2009
  9. Jakub NarebskiFeb 18, 2009
  10. Junio C HamanoFeb 20, 2009
  11. Jakub NarebskiFeb 20, 2009
  12. Addresses with full names in patch emailsMarcel M. Cary, Feb 24, 2009
  13. Jakub NarebskiFeb 24, 2009
  14. Marcel M. CaryFeb 24, 2009
  15. Giuseppe BilottaFeb 18, 2009
  16. Junio C HamanoFeb 18, 2009
  17. Jakub NarebskiFeb 18, 2009
  18. Junio C HamanoFeb 18, 2009
  19. Jakub NarebskiFeb 18, 2009
  20. Marcel M. CaryFeb 19, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.