Junio C Hamano <junkio@xxxxxxx> writes:
>> (Are there any octopus merges in git's history? If not, could I ask
>> for one for pedagogical value?)
>
> git.git itself is full of them, but the very first octopus (it
> actually is a pentapus) is rather nice to watch in gitk:
>
> 211232bae64bcc60bbf5d1b5e5b2344c22ed767e
Having said that, I think it is not a good idea to talk about
octopus in introductory documents. The 'feature' may be unique
to git and some people might even find it cool, but new people
should not be encouraged to use it until they understand the
ramifications.
The first ever octopus merge was just a bundle of five forked
development branches, each of which had only one commit since it
forked from the common parent.
.-a-.
.--b--.
O---c---X
'--d--'
'-e-'
They were independent, un-overlapping changes. "diff-tree -c"
would not show anything, and there was no inherent reason that
one change should come before the others, so in that sense,
presenting this as an octopus was making the history more
truthful than pretending one happened before another.
But octopus has a negative effect on bisecting performance.
Suppose commit X was bad and commit O was good. Because X
bundles five branches into one, and we know one of them
(hopefully) is what introduced the regression, our task is to
find the guilty one commit among five commits. But in order to
do so, we would end up having to test four commits. That is,
knowing that a, b and c are Ok does not give us any useful
information to determine which of d or e is the bad one (after
learning that a, b and c are Ok, we still need to test d and if
it turns out to be Ok then we can finally say e is the bad one).
If I did not do an octopus and laid out the commit ancestry
graph this way when I gave them to Linus:
O--a--b--c--d--e--X
the same bisect would have asked us check c first. If it is
good, then we do not even have to test a or b. The linear part
of the history is what bisect takes advantage of to cut the
search space efficiently, and an octopus actively defeats that.
So doing an octopus is a wrong thing to do, if there is a
possibility that something wrong is found later. So people
should not do an octopus unless the component changes are all
truely trivial.
If you want an esoteric topic for an introductory documentation,
it would be more useful to talk about evil merges (an evil merge
is a merge commit whose result does not match any of its
parents). A good example is found in
git show v1.0.0
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html