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, 19:40 UTC
- Message-ID
- <vpqbp0v2fve.fsf@bauges.imag.fr>
- In-Reply-To
- <AANLkTimR5XfOV-0RZjdyu72E9JdBfr1B+wc=q55V4qH5@mail.gmail.com>
Andrew Garber <andrew@andrewgarber.com> writes:
Show 7 quoted lines
>>> What is the point is finding manually a commit *on the same branch* when >>> the tool can do that for you? > >> Seems to me that this is trying to cram two questions into one: >> >> A) where did branch foo diverge from branch bar and >> B) which commit between that ancestor and bar did things break.
No. What I'm saying is that if you insist in not using bisect, you'll probably have to answer these two questions separately.
Show 6 quoted lines
> To find the answer to A, I generally just do this (using an alias): > > git log --graph --oneline --all > > It takes at most a couple of seconds... hardly what I'd call a manual > process.
Suppose you have a bug in git.git that you see in pu, but not in next. Try finding the common ancestor with your command, and see how long it takes.
Yes, you'll be able to do it, but you still didn't tell us what was wrong with
git bisect start git bisect good origin/next git bisect bad origin/pu ...
which is _way_ faster. And my example took git.git which isn't a very large project, so real-life examples could be much worse.
-- Matthieu Moy http://www-verimag.imag.fr/~moy/