This is the mail archive of the
mailing list for the GCC project.
Re: Moving to git
- From: Jeff Law <law at redhat dot com>
- To: Jakub Jelinek <jakub 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 09:49:15 -0600
- 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 08/24/2015 09:43 AM, 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
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.
A map of key hashes would probably be helpful with this kind of thing.
Major releases, key branch->trunk merge points and the like.
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.).
It'd still be somewhat worse usability wise for you, but it ought to be
ANd like I said before, I'd support a git-hook which bumped some kind of
index at each commit for your workflow.
I'd like to keep the old ones working, but new references should
probably be using the hash id and commit name.
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.
As for how to best keep the old r123456 links working, I don't know.
Presumably those could be mapped behind the scenes to a git id.