On 5/19/19 10:06 PM, Marek Polacek wrote: > On Sun, May 19, 2019 at 01:00:45PM -0700, Andrew Pinski wrote: >> 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. > > Exactly, we have many TBs of prebuilt binaries.
I combine both together, feel free to use my script: https://github.com/marxin/script-misc/blob/master/gcc-bisect.py It uses git repository for navigation, information about branches, tag releases and so on. And then I have a folder with pre-built binaries which are identified by commit hash. That works all fine. Martin > >> One way is store the binaries based on the date that commit happened >> instead. This is a bit more complex but still doable. > > Yeah, I guess we'll have to do something like that, then. :/ > > -- > Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA >