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

Le Saturday 08 November 2008 20:07:53 Jakub Narebski, vous avez écrit :

Francis Galiegue [off-list ref] writes
in "Need help for migration from CVS to git in one go..."

quoted

* 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