git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Marcel M. Cary" <marcel@oak.homeunix.org>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Francis Galiegue <fg@one2team.net>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	Petr Baudis <pasky@suse.cz>
Subject: Re: [RFC] Configuring (future) committags support in gitweb, especially bug linking
Date: Thu, 19 Feb 2009 09:08:05 -0800	[thread overview]
Message-ID: <499D91F5.6010605@oak.homeunix.org> (raw)
In-Reply-To: <200902180438.55081.jnareb@gmail.com>

Jakub Narebski wrote:
> On Tue, 17 Feb 2009, Marcel M. Cary wrote:
>
>> I'm interested in cross-linking bug references in commit messages to
>> a bug tracking system.  I started tinkering a couple weeks ago and am
>> finally understanding that committags encompass this functionality.
>> (From the subject line I first understood "tags" to mean git tags
>> rather than commit message munging.)
>
> What would you name this feature, then?

Heh, I'm not sure.  It's like a filter in the unix pipeline sense, but
"commit message filter" sounds to me like some messages might be
rejected.  Most of the drivers markup static text with HTML tags, but
not all of them.  Maybe "commit message embellishment".

Perhaps a more important question is: will people find the feature once
it's implemented?  I think that won't be a problem provided that it's
listed in the gitweb docs like the other configs.

>> Is the committags idea still under active development?
>
> Well, it is in my todo list, rather further on...

Is any code for it published in a repository anywhere?  I see a branch
jn/gitweb-committag merged into master that looks relevant, but it only
has the sha1 regex improvement.

>> Two regexes would make it easier to configure a driver without
>> needing look-ahead and look-behind assertions.  For example, if you
>> want to match non-negative integers but only in the context of a
>> Resolves-bug header:
>>
>>     Resolves-bug: 1234, 1235
>
> [...]
>> I got the two-regex idea from a spec I ran across while evaluating
>> Subversion:
>>
>>
http://guest:@tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/issuetrackers.txt
>
> You don't need multiple regexps for that, and in above example it is
> used _single_ regexp; only with more than one catching group.

I'm not sure what exactly you propose.  In the second example in the
bugtraq spec, there are two regexes.  Maybe you mean something like
this, but it breaks with three bugs:

    $ perl -MData::Dumper -wne '
        m/^Resolves-bug: (\d+)(?:, (\d+))*/;
        print Dumper([$1, $2, $3, $4]);
    '
    Resolves-bug: 123
    $VAR1 = [
          '123',
          undef,
          undef,
          undef
        ];
    Resolves-bug: 123, 124
    $VAR1 = [
          '123',
          '124',
          undef,
          undef
        ];
    Resolves-bug: 123, 124, 125
    $VAR1 = [
          '123',
          '125',
          undef,
          undef
        ];

Maybe something like this?  But it's limited to an arbitrary number of
bug matches.  Maybe it's good enough for pratical purposes, but it's
prone to unexpected breakage when the user exceeds the threshold of, in
this case, four bugs.

    /^Resolves-bug: (\d+)(?:, (\d+))?(?:, (\d+))?(?:, (\d+))?/


Marcel

  reply	other threads:[~2009-02-19 17:09 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
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 [this message]
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=499D91F5.6010605@oak.homeunix.org \
    --to=marcel@oak.homeunix.org \
    --cc=fg@one2team.net \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=pasky@suse.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).