Re: Moving to git

[Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>]

On 24/08/15 12:43, Jonathan Wakely wrote:
> On 24 August 2015 at 11:42, Eric S. Raymond wrote:
>> Jonathan Wakely <jwakely.gcc@gmail.com>:
>>> On 24 August 2015 at 09:17, Jakub Jelinek wrote:
>>>> The revision ids are also useful for bugzilla, r123456
>>>> links in text pointing to http://gcc.gnu.org/r123456 is significantly
>>>> shorter
>>>
>>> The first six characters of the sha1 is usually enough to
>>> unambiguously identify a commit, so we could easily have
>>> https://gcc.gnu.org/git/f00baa or something similar, if we don't use
>>> git-notes to add a revision to the commits.
>>
>> I recommend *against* using hashes to identify commits.  Here's what I said
>> about it in the NTPsec developers guidelines.
>>
>> === How to refer to previous commits ===
>>
>> The best (most human-friendly) way to reference a commit is by quoting its
>> summary line.  If you need to disambiguate, give its date and author.
> 
> That doesn't really work if we want Bugzilla to automatically turn
> something that looks like a reference to a commit into a hyperlink.
> Currently I can say "caused by r227043" in a bugzilla comment and it
> links to the relevant commit. I don't really want to have to say
> "caused by libstdc++/67294 Don't run timed mutex tests on Darwin" or
> "caused by
> Author: Jonathan Wakely <jwakely@redhat.com>
> Date:   Thu Aug 20 20:36:19 2015 +0000
> "
> 
> It's pretty simple for Bugzilla to look for "r\d+" in comments and
> create a hyperlink to https://gcc.gnu.org/\1 without accessing the
> repository at all. It would not be practical (for every bugzilla
> comment) to search the repo for "libstdc++/67294 Don't run timed mutex
> tests on Darwin" to identify a specific commit and create a link to
> it.
> 

Something like 'git:<short-hash>' ought to be easy enough to write into
BZ (you normally cut-and-paste in this sort of case, anyway) and should
be trivial to write a scanner for.  It's not like these numbers really
have to be ascending in this case.


>> The worst way is to quote its git hash, because humans are not good at
>> keeping random strings of hex digits in working memory.  Besides, hashes
>> will break if the history is ever moved to another VCS or the repository
>> has to be surgically altered.
> 
> We have that situation now with the subversion commit IDs we refer to
> in Bugzilla, that doesn't mean it isn't useful.
>