Re: Why can't I use git-bisect to find the first *good* commit?
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- Mar 28, 2011, 18:23 UTC
- Message-ID
- <vpqvcz35cjk.fsf@bauges.imag.fr>
- In-Reply-To
- <AANLkTinuH4Ut+jtdqRfFrNeXA6JmBK2i0ddCcz4vV6JC@mail.gmail.com>
Andrew Garber <andrew@andrewgarber.com> writes:
Show 6 quoted lines
> On Mon, Mar 28, 2011 at 1:55 PM, Matthieu Moy > <Matthieu.Moy@grenoble-inp.fr> wrote: > >> Then which commit do you specify as "good"? > > Any ancestral commit *on the same branch* which is know to be working.
What is the point is finding manually a commit *on the same branch* when the tool can do that for you? You don't know how old the breakage is, so finding the first good commit will take some time. Knowing that the other branch is good gives you a hint that the common ancestor between branches should be good, so a good start would be to find the common ancestor.
But again, why would you insist in doing that manually?
> Isn't the whole point of git bisect is to do binary search through > time?
No. Bisect does a search through a DAG. And that is the whole point of bisect: doing a binary search through time is something you could do manually. That would be less convenient, but still workable. git bisect is far more clever, and does something you could hardly do manually, or at least not without getting headaches.
> Perhaps you could give a concrete example of where you could use it > for multiple branches simultaneously?
Well, see my previous email.
-- Matthieu Moy http://www-verimag.imag.fr/~moy/