Re: [DRAFT] Branching and merging with git

From: Junio C Hamano <junkio@cox.net>
Date: Nov 18, 2006, 01:11 UTC
Message-ID: <7vslghftix.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7virhdh9j8.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 7 quoted lines

>> (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