> Dear diary, on Wed, Oct 18, 2006 at 11:28:32AM CEST, I got a letter
> where Erik B?gfors <zindar@gmail.com> said that...
> > On 10/18/06, Petr Baudis <pasky@suse.cz> wrote:
> > >Dear diary, on Wed, Oct 18, 2006 at 02:30:14AM CEST, I got a letter
> > >where Aaron Bentley <aaron.bentley@utoronto.ca> said that...
> > >> Petr Baudis wrote:
> > >> > Another aspect of this is that Git (Linus ;) is very focused on getting
> > >> > the history right, nice and clean (though it does not _mandate_ it and
> > >> > you can just wildly do one commit after another; it just provides tools
> > >> > to easily do it).
> > >>
> > >> Yes, rebasing is very uncommon in the bzr community. We would rather
> > >> evaluate the complete change than walk through its history. (Bundles
> > >> only show the changes you made, not the changes you merged from the
> > >> mainline.)
> > >>
> > >> In an earlier form, bundles contained a patch for every revision, and
> > >> people *hated* reading them. So there's definitely a cultural
> > >> difference there.
> > >
> > >BTW, I think what describes the Git's (kernel's) stance very nicely is
> > >what I call the Al Viro's "homework problem":
> > >
> > >
http://lkml.org/lkml/2005/4/7/176
> > >
> > >If I understand you right, the bzr approach is what's described as "the
> > >dumbest kind" there? (No offense meant!)
> >
> > Yes and no, The bundle includes both the full final thing, and each
> > step along the way. Each step along the way is something you'll get
> > when you merge it.
> >
> > Once merged, it will be "next one" in the description above. It would
> > typically look something like this in "bzr log"(shortened) In this
> > example, doing C requires doing A and B as well...
> >
> > committer:
foobar@foobar.com
> > message: merged in C
> > -------
> > committer:
bar@bar.com
> > message: opps, fix bug in A
> > -------
> > committer:
bar@bar.com
> > message: implement B
> > -------
> > committer:
bar@bar.com
> > message: implement A
> >
> > So, you'll get full history, including errors made :) You can also
> > see who approved it to this branch (foobar) and who did the actual
> > work (bar)
>
> I see, that's what I've been missing, thanks. So it's the middle path
> (as any other commonly used VCS for that matter, expect maybe darcs?;
> patch queues and rebasing count but it's a hack, not something properly
> supported by the design of Git, since at this point the development
> cannot be fully distributed).
>
> I also assume that given this is the case, the big diff does really not
> serve any purpose besides human review?
>
> But somewhere else in the thread it's been said that bundles can also
> contain merges. Does that means that bundles can look like:
>
> 1
> / \
> 2 4
> | | _
> 3 5 |
> \ / | a bundle
> 6 |
> ~
>
> In that case, against what the big diff from 6 is done? 2? 4? Or even 1?
