Andrew Garber [off-list ref] writes:
On Mon, Mar 28, 2011 at 1:55 PM, Matthieu Moy
[off-list ref] wrote:
quoted
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/
On 28 March 2011 20:23, Matthieu Moy [off-list ref] wrote:
Andrew Garber [off-list ref] writes:
quoted
On Mon, Mar 28, 2011 at 1:55 PM, Matthieu Moy
[off-list ref] wrote:
quoted
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.
This doesn't make a lot of sense to me. It is just as likely NOT to be useful.
It could just as easily have been fixed in the other branch. So
knowing its good wont tell you where it was broken.
This started off with:
o--o--o--B
/
--o--o--o--o--G
So lets say that the reality of each node looks like this:
B--B--B--B*
/
--B--B--B--G--G*
How does knowing that G* is good help us find what broke B* again?
Your description matches the case of something like this:
B--B--B--B*
/
--G--G--G--G--G*
But what about something like this:
Bx--B--B--B*
/
--Gz--By--B--Gx--G*
How does knowing that G* is good help you to find that Bx broke the
code in the B* branch again?
Presumably 'By' broke the G* branch which was then fixed by Gx and
none of this information helps you at all identify that Bx broke the
B* branch.
Whereas a plain binary search on the B* branch would eventually find
that Bx was responsible.
quoted
Perhaps you could give a concrete example of where you could use it
for multiple branches simultaneously?
Well, see my previous email.
Where you said "It's not uncommon in real life to face the "it works
in branch foo but
not in branch bar, where did it break?" problem. And one expects a great
tool such as Git to be able to answer it."
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.
Of course im probably missing something important here. Id like to
know what it is tho. :-)
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
On 03/28/2011 08:57 PM, demerphq wrote:
On 28 March 2011 20:23, Matthieu Moy[off-list ref] wrote:
quoted
Andrew Garber[off-list ref] writes:
quoted
On Mon, Mar 28, 2011 at 1:55 PM, Matthieu Moy
[off-list ref] wrote:
quoted
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.
This doesn't make a lot of sense to me. It is just as likely NOT to be useful.
It could just as easily have been fixed in the other branch. So
knowing its good wont tell you where it was broken.
This started off with:
o--o--o--B
/
--o--o--o--o--G
So lets say that the reality of each node looks like this:
B--B--B--B*
/
--B--B--B--G--G*
How does knowing that G* is good help us find what broke B* again?
Because if G* is good and B* is bad, git-bisect knows to look for
the merge-base (the leftmost lower B in your graph) to know that
it's not looking at uninteresting commits.
Your description matches the case of something like this:
B--B--B--B*
/
--G--G--G--G--G*
But what about something like this:
Bx--B--B--B*
/
--Gz--By--B--Gx--G*
How does knowing that G* is good help you to find that Bx broke the
code in the B* branch again?
Because it helps locate Gz as the common ancestor between G* and B*.
To bisect a problem with B*, you'd mark B* as bad and, assuming Gz is
a stable release from which the feature-branch B has arisen, you'd
mark Gz as good. Then bisect will quite quickly find that Bx is the
culprit.
Or, if G* works well but B* does not and you can't be arsed to locate
the common ancestor yourself, you mark G* as good and B* as bad and then
git-bisect will automatically reset the "good" mark from G* to Gz. This
ofcourse doesn't work when the two points in doesn't share a common
ancestor, although that should be a rare occasion indeed and won't
make much sense.
Presumably 'By' broke the G* branch which was then fixed by Gx and
none of this information helps you at all identify that Bx broke the
B* branch.
You're right. For that, you'd need two different bisects. If the two
breakages are identical (an unlikely situation, but still), you'd end
up with git-bisect finding a single commit when marking GB* (the merge
of G* and B*) as bad and Gz as good. Which one is hard to tell though.
But then again, git-bisect has never claimed to be able to locate all
bugs at once. It can just help you locate where a particular bug was
introduced.
There are some cases where it will fail quite gruesomely though. When
one bug is covered by another and fixing the first bug uncovers the
one you're bisecting for. Even then it will still cut down considerably
on time spent doing implemetation analysis (aka "staring at code").
Whereas a plain binary search on the B* branch would eventually find
that Bx was responsible.
True, but a binary search would mean about a bazillion git-bisect runs
on large and complex history (such as the kernel, or git itself) when
the bug is located in an already merged feature-branch, but noone knows
which one.
quoted
quoted
Perhaps you could give a concrete example of where you could use it
for multiple branches simultaneously?
Well, see my previous email.
Where you said "It's not uncommon in real life to face the "it works
in branch foo but
not in branch bar, where did it break?" problem. And one expects a great
tool such as Git to be able to answer it."
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.
The only question git-bisect tries to answer is "which is the first
bad commit". If you want the implementation details, I suggest you
read the code, but naturally it knows how to walk the DAG it's
inspecting and naturally it tries to make life easier for the human
it inevitable serves.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.