Johannes Schindelin [off-list ref] writes:
You are opening a can of worms here, and I doubt that this is a good idea.
git-bisect as-is has very precise, and _simple_ semantics, and users
should really know what they are doing (i.e. not marking something as
"good" which is on a branch containing a fix).
Trying to be too clever here might just make the whole tool rather
useless.
Have you read the original thread yet? I do not think this is trying to
be clever at all, but trying to be helpful.
As you explained, bisection *requires* that Good is ancestor of Bad.
---o---?---?---?---x
Good Bad
But in real life, things are more like "Today's master does not work, but
I am sure it used to work at 1.5.6.2". I happen to always merge all of
'maint' to 'master' before pushing them out, so a good topology is
guaranteed, but not everybody does this (it takes careful planning what to
apply to 'maint' and where to fork topics from, and maintainers are not
perfect):
Good
?---o (maint)
/
---?---?---?---?---x (master)
MB Bad
People _will_ face such a topology. If the users Know Better, they will
test MB=$(merge-base master maint) first to see if it is broken, and then
the world will have two possibilities:
(1) Good
?---o (maint)
/
---o---?---?---?---x (master)
Good Bad
(2) Good
?---o (maint)
/
---x---?---?---?---x (master)
Bad Bad
If (1), you go ahead with the usual bisection. If (2), you cannot even
bisect. Instead, you flip good and bad to find the "fix" in the side
branch (the answer has to be either the tip of maint or one previous in
the picture) to forward port to, either by merging 'maint' to 'master' or
cherry-picking.
The idea to check merge-base first is about automating this process (I
admit I still haven't looked at Christian's patch text yet).
Le vendredi 11 juillet 2008, Junio C Hamano a écrit :
But in real life, things are more like "Today's master does not work, but
I am sure it used to work at 1.5.6.2". I happen to always merge all of
'maint' to 'master' before pushing them out, so a good topology is
guaranteed, but not everybody does this (it takes careful planning what
to apply to 'maint' and where to fork topics from, and maintainers are
not perfect):
Good
?---o (maint)
/
---?---?---?---?---x (master)
MB Bad
People _will_ face such a topology. If the users Know Better, they will
test MB=$(merge-base master maint) first to see if it is broken, and then
the world will have two possibilities:
(1) Good
?---o (maint)
/
---o---?---?---?---x (master)
Good Bad
(2) Good
?---o (maint)
/
---x---?---?---?---x (master)
Bad Bad
If (1), you go ahead with the usual bisection. If (2), you cannot even
bisect. Instead, you flip good and bad to find the "fix" in the side
branch (the answer has to be either the tip of maint or one previous in
the picture) to forward port to, either by merging 'maint' to 'master' or
cherry-picking.
The idea to check merge-base first is about automating this process (I
admit I still haven't looked at Christian's patch text yet).
Well in case (2) my patch does:
-------
cat >&2 <<EOF
The merge base $_badmb is bad.
This means the bug has been fixed between $_badmb and $_g.
EOF
exit 3
-------
but this can be improved upon in some latter patches.
Thanks,
Christian.
Hi,
On Thu, 10 Jul 2008, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
You are opening a can of worms here, and I doubt that this is a good idea.
git-bisect as-is has very precise, and _simple_ semantics, and users
should really know what they are doing (i.e. not marking something as
"good" which is on a branch containing a fix).
Trying to be too clever here might just make the whole tool rather
useless.
Have you read the original thread yet? I do not think this is trying to
be clever at all, but trying to be helpful.
As you explained, bisection *requires* that Good is ancestor of Bad.
Thanks, I got that already.
Of course it can be that the user commits a pilot error and says "but that
unrelated version was good", while the fork point(s) between good and bad
was bad (and this might be even the intention of the user, to find _one_
commit that introduced the bug).
Speaking of plural, what if some of the merge bases are good, some are
bad?
Without carefully thinking it through, you might even _break_ the tool.
All I was proposing is keeping the current semantics, keeping the
mechanism simple, and therefore reliable.
Ciao,
Dscho