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

[Andrew Pinski]

On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Sun, May 19, 2019 at 03:21:01PM -0400, Marek Polacek wrote:
> > On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
> > > On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> > > > Do we really need a commit integer numbers after the transition? I know
> > > > we're used to it.
> > > > But git commit hash provides that same.
> > >
> > > Revision numbers are nice short text strings, and from a revision number
> > > you can see approximately when it happened, and from two revision numbers
> > > on the same branch you can trivially tell which one is older.  Those are
> > > nice features.  But we can live without it, IMO.
> >
> > Since I do many bisections a day, losing this capability would be Very Bad.
> > Without it, there's no range, and without a range, there's nothing to _bisect_.
> >
> > I bisect by hand, so if I have cc1plus.250000 (good) and cc1plus.260000 (bad),
> > I know the commit I'm looking for is within that range, and I can easily split
> > the range, and it's at most log n steps.  Whereas if we had e.g. cc1plus.de28b0
> > and cc1plus.a9bd4d, I couldn't do it anymore.
>
> 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.
One way is store the binaries based on the date that commit happened
instead.  This is a bit more complex but still doable.

Thanks,
Andrew Pinski

>
>
> Segher