Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

Re: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev

From: Christian Couder <hidden>
Date: 2016-06-15 22:44:55

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help