Dnia niedziela 9. listopada 2008 00:27, Francis Galiegue napisał: > Le Saturday 08 November 2008 23:35:48 Jakub Narebski, vous avez écrit : >>> 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) >>> 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). [...] >>> 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@xxxxxxxxxxx' 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 >> >>> 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@xxxxxxxxxxx> would be replaced by {<span class="signoff">}Signed-off-by: A U Thor <author@xxxxxxxxxxx>{</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). ..................................................................... > [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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
