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). Jakub
