From: Francis Galiegue <fg@one2team.net>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC] Configuring (future) committags support in gitweb
Date: Sat, 8 Nov 2008 21:02:44 +0100 [thread overview]
Message-ID: <200811082102.44919.fg@one2team.net> (raw)
In-Reply-To: <200811082007.55045.jnareb@gmail.com>
Le Saturday 08 November 2008 20:07:53 Jakub Narebski, vous avez écrit :
> Francis Galiegue <fg@one2team.net> 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
next prev parent reply other threads:[~2008-11-08 20:06 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-08 19:07 [RFC] Configuring (future) committags support in gitweb Jakub Narebski
2008-11-08 20:02 ` Francis Galiegue [this message]
2008-11-08 22:35 ` Jakub Narebski
2008-11-08 23:27 ` Francis Galiegue
2008-11-09 0:25 ` Jakub Narebski
2009-02-17 15:32 ` [RFC] Configuring (future) committags support in gitweb, especially bug linking Marcel M. Cary
2009-02-18 3:00 ` [PATCH RFC 1/2] gitweb: Fix warnings with override permitted but no repo override Marcel M. Cary
2009-02-18 7:41 ` Giuseppe Bilotta
2009-02-18 8:40 ` Junio C Hamano
2009-02-18 13:09 ` Jakub Narebski
2009-02-18 19:02 ` Junio C Hamano
2009-02-18 3:00 ` [PATCH RFC 2/2] gitweb: Hyperlink multiple git hashes on the same commit message line Marcel M. Cary
2009-02-18 21:55 ` Jakub Narebski
2009-02-20 8:35 ` Junio C Hamano
2009-02-20 11:46 ` Jakub Narebski
2009-02-24 15:38 ` Addresses with full names in patch emails Marcel M. Cary
2009-02-24 15:58 ` Jakub Narebski
2009-02-24 16:33 ` [PATCH RFC 2/2] gitweb: Hyperlink multiple git hashes on the same commit message line Marcel M. Cary
2009-02-18 3:38 ` [RFC] Configuring (future) committags support in gitweb, especially bug linking Jakub Narebski
2009-02-19 17:08 ` Marcel M. Cary
2009-06-19 14:13 ` [RFC PATCH 1/2] gitweb: Hyperlink various committags in commit message with regex Marcel M. Cary
2009-06-22 11:18 ` Jakub Narebski
2009-11-18 6:22 ` [RFC PATCH 0/6] Second round of committag series Marcel M. Cary
2009-11-18 6:22 ` [RFC PATCH 1/6] gitweb: Hyperlink committags in a commit message by regex matching Marcel M. Cary
2009-11-18 6:22 ` [RFC PATCH 2/6] gitweb: Add second-stage matching of bug IDs in bugzilla committag Marcel M. Cary
2009-11-18 6:22 ` [RFC PATCH 3/6] gitweb: Allow finer-grained override controls for committags Marcel M. Cary
2009-11-18 6:22 ` [RFC PATCH 4/6] gitweb: Allow committag pattern matches to span multiple lines Marcel M. Cary
2009-11-18 6:22 ` [RFC PATCH 5/6] gitweb: Allow per-repository definition of new committags Marcel M. Cary
2009-11-18 6:22 ` [RFC PATCH 6/6] gitweb: Add _defaults_ keyword for feature lists in project config Marcel M. Cary
2009-11-18 8:20 ` [RFC PATCH 1/6] gitweb: Hyperlink committags in a commit message by regex matching Petr Baudis
2009-11-18 8:26 ` Petr Baudis
2009-11-20 23:24 ` [RFC PATCH 0/6] Second round of committag series Jakub Narebski
2009-06-19 14:13 ` [RFC PATCH 2/2] gitweb: Add second-stage matching of bug IDs in bugzilla committag Marcel M. Cary
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200811082102.44919.fg@one2team.net \
--to=fg@one2team.net \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.