This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Moving to git

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

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]