Re: Git counterpart to SVN bugtraq properties?

From: Marc Strapetz <marc.strapetz@syntevo.com>
Date: Jul 18, 2013, 13:32 UTC
Message-ID: <51E7EE83.5020905@syntevo.com>
In-Reply-To: <20130717133357.GB2337@serenity.lan>

On 17.07.2013 15:33, John Keeping wrote:

Show 15 quoted lines

> On Wed, Jul 17, 2013 at 03:03:14PM +0200, Marc Strapetz wrote:
>> I'm looking for a specification or guidelines on how a Git client should
>> integrate with bug tracking systems. For SVN, one can use
>> bugtraq-properties [1] to specify e.g. the issue tracker URL or how to
>> parse the bug ID from a commit message. AFAIU, there is nothing
>> comparable for Git [2]? If that's actually the case, is someone
>> interested in working out a similar specification for Git?
>>
>> [1] http://code.google.com/p/tortoisesvn/source/browse/tags/version_1.2.0/doc/issuetrackers.txt
>>
>> [2] http://stackoverflow.com/questions/17545548
> 
> The Git way to record the issue ID as a footer in the commit message.
> See for example [1].  Although I'm not aware of any standard for naming
> this footer.

I wasn't aware of that and probably I'm not the only one. For instance, we are using JIRA and typical commit messages look like

 SG-1234: fix something

 More details on what has been fixed ...

So the issues ID is present in the first line. This has the advantage that every GUI client will display it, as usually the short version of the commit message (which is used everywhere) reaches up to the first dot or LF. Hence it's pretty easy to display a hyperlink for the "SG-1234" part. bugtraq properties allow to define whether the issue ID should be appended to the top or bottom of the commit message. So looks like such an option makes sense for Git as well.

> In terms of recording the URL and other data, I think you'd want a
> dotfile in the repository (perhaps .bugzilla).  This shoudld probably be
> in the gitconfig format, like .gitmodules.

Having such a file sounds reasonable for storing the defaults, though let's call it .bugtraq or have some other more general name. Similar to .gitmodules, it makes sense to have the actual properties stored in $GIT_DIR/config which can be "initialized" from this .bugtraq file. The arguments are the same as for submodules: URLs stored in .bugtraq might need to be changed, depending on the client location (firewall/proxy...).

Or we could just have $GIT_DIR/config properties *optionally*, overriding the .bugtraq properties, as for most users the default configuration will work fine anyway.

> I think "all" it needs is to draw up a spec for the names of keys and
> format of their values, along with the format of footer(s) identifying
> issues associated with a commit and to persuade UI developers to support
> it... ;-)

I'll try to compose something here. But I'm wondering how we could attract a couple of developers or users to join in this discussion?

-Marc