On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool <seg...@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