Le Saturday 08 November 2008 20:07:53 Jakub Narebski, vous avez écrit : > Francis Galiegue <fg@xxxxxxxxxxxx> writes > in "Need help for migration from CVS to git in one go..." > > > * third: also Bonsai-related; Bonsai can link to Bugzilla by > > matching (wild guess) /\b(?:#?)(\d+)\b/ and transforming this into > > http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have > > this built-in? (haven't looked yet) Is this planned, or has it been > > discussed and been considered not worth the hassle? > > Here below there is proposal how the committags support could look like > for gitweb _user_, which means how to configure gitweb to use (or do not > use) committags, how to configure committags, and how to define new > committags. > Your proposal goes much further than my initial question, but I thought I'd jump in anyway :p > Committags are "tags" in commit messages, expanded when rendering commit > message, like gitweb now does for (shortened) SHA-1, converting them to > 'object' view link. It should be done in a way to make it easy > configurable, preferably having to configure only variable part, and not > having to write whole replacement rule. > > Possible committags include: _BUG(n)_, bug _#n_, _FEATURE(n), > Message-Id, plain text URL e.g. _http://repo.or.cz_, spam protecting > of email addresses, "rich text formatting" like *bold* and _underline_, > syntax highlighting of signoff lines. > What do you mean with "not having to write whole replacement rule"? > 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? If so, might I suggest that an "alt" tells "Only show commits signed off by this person"? 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... Or would that be: my $sha1_re = qr/[a-z[0-9]{40}/; /(?:(?i:commit\s+))?\b($sha1_re)\b/ => [link to commit $1] /(?:(?i:tree\s+))\b($sha1_re)\b)/ => [link to tree $1] /(?:(?:tag\s+))\b($sha1_re)\b)/ => [link to tag $1] Finally, is there any reason to think that a sha1 or signoff committag will ever need to be overriden in some way? > possible actions > for committag driver include: > * link: replace $match by '_<a href="$link">_$match_</a>_' > * html: replace $match by '_$html_' > * text: replace $match by '$text' > where '_a_' means that 'a' is treated as HTML, and is not expanded > further, and 'b' means that it can be further expanded by later > committags, and finally is HTML-escaped (esc_html). > What use do you see for the html match? Just asking... And I don't see what you '_a_' and '_b_' are about... -- fge -- 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
