On 24/08/15 16:43, Jakub Jelinek wrote: > On Mon, Aug 24, 2015 at 09:34:41AM -0600, Jeff Law wrote: >> On 08/24/2015 02:17 AM, Jakub Jelinek wrote: >>> On Thu, Aug 20, 2015 at 04:09:39PM -0400, Jason Merrill wrote: >>>> On 08/20/2015 02:23 PM, Jeff Law wrote: >>>>> I suspect Jakub will strongly want to see some kind commit hook to >>>>> associate something similar to an SVN id to each git commit to support >>>>> his workflow where the SVN ids are associated with the compiler >>>>> binaries he keeps around for very fast bisection. I think when we >>>>> talked about it last year, he just needs an increasing # for each >>>>> commit, presumably starting with whatever the last SVN ID is when we >>>>> make the change. >>>> >>>> Jakub: How about using git bisect instead, and identify the compiler >>>> binaries with the git commit sha1? >>> >>> That is really not useful. While you speed it bisection somewhat by >>> avoiding >>> network traffic and communication with a server, there is still significant >>> time spent on actually building the compiler. >> I thought the suggestion was to use the git hash to identify the builds you >> save. >> >> So you'd use git bisect merely to get the hash id. Once you've got the git >> hash, you can then use that to find the right cc1/cc1plus/f95 that you'd >> previously built. >> >> It's not perfect (since you can't just look git hashes and know which one is >> newer). > > But then you are forced to use git bisect all the time, because the hashes > don't tell you anything. > Most often even before writing a script I try a couple of compiler versions > by hand if I have some extra info (this used to work a 3 years ago, broke in > the last couple of days, etc.). > Perhaps I could touch the cc1.sha1hash files with timestamps corresponding to > the date/time of the commit, and keep them sorted in some file manager by > timestamps, still it would be worse usability wise. > Not to mention we should keep the existing r123456 comments in bugzilla > working, and I'm not convinced keeping a SVN version of the repository > (frozen) for that purpose is the best idea. > > Jakub >
Why not use the output of 'git show -s --format=%ct-%h'? $ git show -s --format=%ct-%h master 1440153969-f57da59 That gives you a unix timestamp for the commit, followed by the hash. Now you've got a fully ordered way of referring to the commit, but still have access to the hash code.
