[asterisk-dev] Tagging commits with issue numbers
Kevin P. Fleming
kpfleming at digium.com
Mon Aug 29 07:06:03 CDT 2011
On 08/28/2011 01:09 PM, Tilghman Lesher wrote:
> On Sunday 28 August 2011 11:59:30 Tzafrir Cohen wrote:
>> On Sun, Aug 28, 2011 at 11:01:16AM -0500, Tilghman Lesher wrote:
>>> On Sunday 28 August 2011 05:32:01 Tzafrir Cohen wrote:
>>>> On Tue, Aug 16, 2011 at 11:31:58AM -0400, Russell Bryant wrote:
>>>>> Related wiki page which may need some updating:
>>>>>
>>>>> https://wiki.asterisk.org/wiki/display/AST/Commit+Messages
>>
>> [snip]
>>
>>>> Also, if the bug tracker will display the list of patches
>>>> effectivly, why bother with including part of that information in
>>>> patches (only one direction)? Recall that the URL included there is
>>>> invalid anyway.
>>>
>>> Because there may be more than one patch on the issue, solving the
>>> problem in different ways. The commit message disambiguates as to
>>> which patch was actually applied.
>>
>> In that case it is the actual commit that should be used, and not the
>> attached patch. The attached patch often gets reworked before getting
>> applied. Pointing people to the patch may actually be slightly
>> misleading.
>>
>> But anyway, I have two separate issues with the svnmerge commit message:
>>
>> 1. It is very verbose, but adds very little useful information
>> 2. If I have to include the commit number, which gets in my way.
>>
>> It seems I'm on my own with (2), so I'll consider (1) here:
>>
>> Consider
>> http://svnview.digium.com/svn/asterisk?view=revision&revision=333410
>>
>> You get a lengthy header telling you that this is a merge of r333378
>> from https://origsvn.digium.com/svn/asterisk/branches/1.8
>> (which is an invalid URL for most people).
>
> This was solved at one point; I believe it was in how the message was
> posted to Mantis, by doing a simple string replacement. We could probably
> do the same thing in the svnmerge script.
>
>> This is followed by an extra line of mostly useless metadata (it may
>> have been useful if it were at the end). Only then you get the actual
>> commit subject.
>>
>> So, why not replace all of those headers and indentations with yet
>> another tag at the bottom of the message?
>>
>> Original-Commit: r333378, branches/1.8
>>
>>
>> The rule is that you add it at the end, and thus the one in trunk will
>> have:
>>
>> Original-Commit: r333378, branches/1.8
>> Original-Commit: r333410, branches/10
>
> That sounds acceptable to me. The main issue is going to be modifying
> the svnmerge python script to change how the message is constructed.
The version of svnmerge we use lives in our public repotools repository;
if anyone wants to modify it to produce a more useful merge commit
message, feel free to post patches (or modify it yourself if you have
permissions to do so). It's probably also worth checking to see what
status of the 'upstream' version is... it's been a very long time since
we pulled our copy and started hacking on it.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
More information about the asterisk-dev
mailing list