On 24/08/15 12:43, Jonathan Wakely wrote: > On 24 August 2015 at 11:42, Eric S. Raymond wrote: >> Jonathan Wakely <jwakely....@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 <jwak...@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. >