From: Junio C Hamano <junkio@cox•net>
To: linux@horizon•com
Cc: git@vger•kernel.org
Subject: Re: [DRAFT] Branching and merging with git
Date: Fri, 17 Nov 2006 17:11:34 -0800 [thread overview]
Message-ID: <7vslghftix.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <7virhdh9j8.fsf@assigned-by-dhcp.cox.net> (Junio C. Hamano's message of "Fri, 17 Nov 2006 16:40:27 -0800")
Junio C Hamano <junkio@cox•net> 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
next prev parent reply other threads:[~2006-11-18 1:11 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-16 22:17 [DRAFT] Branching and merging with git linux
2006-11-16 23:47 ` Junio C Hamano
2006-11-17 1:13 ` linux
2006-11-17 1:31 ` Junio C Hamano
2006-11-17 1:09 ` Junio C Hamano
2006-11-17 3:17 ` linux
2006-11-17 5:55 ` Junio C Hamano
2006-11-17 9:37 ` Jakub Narebski
2006-11-17 9:41 ` Jakub Narebski
2006-11-17 10:37 ` Jakub Narebski
2006-11-17 15:32 ` Theodore Tso
2006-11-17 15:57 ` Sean
2006-11-17 16:19 ` Nguyen Thai Ngoc Duy
2006-11-17 16:25 ` Marko Macek
2006-11-17 16:33 ` Petr Baudis
2006-11-17 16:34 ` Sean
[not found] ` <20061117113404.810fd4ea.seanlkml@sympatico.ca>
2006-11-17 16:53 ` Petr Baudis
2006-11-17 17:01 ` Sean
[not found] ` <20061117120154.3eaf5611.seanlkml@sympatico.ca>
2006-11-17 21:31 ` Petr Baudis
2006-11-17 22:36 ` Chris Riddoch
2006-11-17 22:50 ` Petr Baudis
2006-11-17 23:30 ` Sean
2006-11-17 18:21 ` J. Bruce Fields
2006-11-18 0:13 ` linux
2006-11-18 0:32 ` Jakub Narebski
2006-11-18 0:40 ` Junio C Hamano
2006-11-18 1:11 ` Junio C Hamano [this message]
2006-11-20 23:51 ` [DRAFT 2] " linux
2006-11-22 11:02 ` [Patch to DRAFT 2 (1/2)] " Junio C Hamano
2006-11-22 11:02 ` [Patch to DRAFT 2 (2/2)] " Junio C Hamano
2006-11-22 13:36 ` Rene Scharfe
2006-12-04 1:19 ` [DRAFT 2] " J. Bruce Fields
2006-12-04 7:23 ` J. Bruce Fields
2006-12-04 10:56 ` Johannes Schindelin
2006-12-15 21:38 ` Jakub Narebski
2006-12-15 21:41 ` J. Bruce Fields
2006-11-22 11:51 ` [DRAFT] " Junio C Hamano
2006-11-19 17:50 ` J. Bruce Fields
2006-11-19 17:59 ` Git manuals Petr Baudis
2006-11-19 18:16 ` Jakub Narebski
2006-11-19 19:50 ` Robin Rosenberg
2006-11-19 19:36 ` J. Bruce Fields
2006-11-26 4:01 ` [PATCH] Documentation: add a "git user's manual" J. Bruce Fields
2006-11-17 17:44 ` [DRAFT] Branching and merging with git J. Bruce Fields
2006-11-17 18:16 ` Jakub Narebski
2007-01-03 17:04 ` Theodore Tso
2007-01-03 17:08 ` Junio C Hamano
2007-01-04 5:28 ` linux
2007-01-04 6:11 ` Junio C Hamano
2007-01-07 23:44 ` J. Bruce Fields
2007-01-08 0:24 ` Junio C Hamano
2007-01-08 2:35 ` J. Bruce Fields
2007-01-08 13:04 ` David Kågedal
2007-01-08 14:03 ` Theodore Tso
2007-01-09 2:41 ` J. Bruce Fields
2007-01-09 8:46 ` Andreas Ericsson
2007-01-09 15:49 ` J. Bruce Fields
2007-01-09 16:58 ` Theodore Tso
2007-01-10 4:15 ` J. Bruce Fields
2007-01-08 0:40 ` Theodore Tso
2007-01-08 0:46 ` J. Bruce Fields
2007-01-08 1:22 ` Jakub Narebski
2007-01-08 1:46 ` Horst H. von Brand
2007-01-08 2:22 ` J. Bruce Fields
2007-01-08 12:38 ` Guilhem Bonnefille
2007-01-09 4:17 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vslghftix.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=linux@horizon$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox