Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Jakub Jelinek <jakub@redhat.com>]

On Mon, May 20, 2019 at 03:56:35PM +0200, Florian Weimer wrote:
> * Andrew Pinski:
> 
> > On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> 
> >> Git can bisect automatically just fine, there is no upside to doing things
> >> manually.  In git there are various handy ways of referring to commits; you
> >> can say  master@{3 days ago}  for example, or zut@{31}  to get the 31st
> >> commit back on branch "zut", etc.  See "man gitrevisions".
> >
> > Well one thing is if you have prebuilt cc1/cc1plus.  So it is not
> > really doing a manual bisect per-say but rather it is doing a manual
> > bisect using prebuilt binaries and knowing which one comes before
> > which one.
> 
> If GCC policy is to reject merge commits, a command similar to
> “git log --pretty=oneline | wc -l” gives something that is very
> much like a Subversion revision number, in the sense that it matches
> the commit ordering and that the assigned numbers remain stable
> over time.

That is way too slow for our purposes, note we have at least 150000 trunk
commits at least, git log --pretty=oneline | wc -l takes on my box more than
1.4 seconds.

So far the best suggestion I was given for this was:
> so, if we have tags like r163 for 163000'th commit then git describe --all --match 'r[0-9]*' whatever | sed 's/^r\([0-9]\)*-\([0-9]\)*-.*$/\1\2/'
> would give us the r163147 (except it doesn't handle the r163000 commit or < 100 commits after it, to be fixed)
matz> yeah.  With the other direction then being as discussed above (limiting the git log revision to just the couple thousands in range).  One thing to consider: having a zillion tags locally can make other operations slow (as the mapping from SHA1 to tag is slow), so if really using rXXX tags it should probably be a larger range than just 1000 revisions.

Thus perhaps tag in a post-commit hook every 5000th commit and handle the
rest in some git alias command or script that.  We need a quick way to map
between these revisions and hashes bidirectionally.
Unfortunately, the above is just a per-branch number rather than branch
number common to trunk and official release branches.

	Jakub