This is the mail archive of the
mailing list for the GCC project.
Re: Moving to git
- From: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, Jeff Law <law at redhat dot com>
- Cc: Jason Merrill <jason at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 24 Aug 2015 16:54:18 +0100
- Subject: Re: Moving to git
- Authentication-results: sourceware.org; auth=none
- References: <55D61512 dot 8010002 at redhat dot com> <55D61B23 dot 3000309 at redhat dot com> <55D63403 dot 4000603 at redhat dot com> <20150824081741 dot GB9425 at tucnak dot redhat dot com> <55DB3991 dot 4030701 at redhat dot com> <20150824154355 dot GM9425 at tucnak dot redhat dot com>
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
>> 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
> 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.
Why not use the output of 'git show -s --format=%ct-%h'?
$ git show -s --format=%ct-%h master
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.