Re: [RFC] Configuring (future) committags support in gitweb, especially bug linking

From: Marcel M. Cary <marcel@oak.homeunix.org>
Date: Feb 19, 2009, 17:08 UTC
Message-ID: <499D91F5.6010605@oak.homeunix.org>
In-Reply-To: <200902180438.55081.jnareb@gmail.com>

Jakub Narebski wrote:

Show 9 quoted lines

> 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.

Show 12 quoted lines

>> 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