This is the mail archive of the
mailing list for the GCC project.
Re: Moving to git
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 24 Aug 2015 10:17:41 +0200
- 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>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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. So, if you use bisection only
occassionally, git bisect may be useful, but if you use it often, it is
still too slow. The way I use bisection is that either I have for every 50-200
commits a cc1/cc1plus/f951 compiler already built (that is on my ws) or for
every non-library commit to the branch that could affect the compiler (no
testsuite changes etc.). And for those really identifying them by sha1
hashes is significantly worse than using monotonically increasing small
number, sha1 hashes are impossible to remember, and you don't know what is
earlier and what is later from just looking at it.
The revision ids are also useful for bugzilla, r123456
links in text pointing to http://gcc.gnu.org/r123456 is significantly
shorter and again gives the idea what is earlier and what is later, over
referencing the sha1 hashes in the text.
Looking at man git-notes, can we e.g. in a some git commit hook
do notes.rewrite.<command> and assign to each trunk or release branch
commit the revision ids starting from the last svn rev id we'll get before
the conversion (and for the converted commits from svn too), remember it
both Notes: of the commit and perhaps some on
the side file (or files, say for every 1000 revision ids), which would
translate the revision ids to the sha1 hashes?
Then http://gcc.gnu.org/r123456 could keep working, we could mention the
revision numbers in gcc-cvs mails too (here I'd prefer not to send diffs
to that mailing list, but only lists of changed files like now, plus URL to
the commit, the revision id and sha1 hash), it could be mentioned in gcc
--version too (again, holds more information than much longer sha1 sum).