[IPython-dev] Bazaar on OS X

[David Cournapeau]

On Mon, 2008-06-30 at 08:06 +0200, Stéfan van der Walt wrote:
> 
> Knowing that bzr preserves the mainline, looks like you did:
> 
>  /------B ----- C -------.------> merge -> F
> A -                       /
>  \------D ------ E ------/
> 

Yes, I merged D/E into the top branch in both git and bzr cases, I
should have been clearer here.

> 
> `pull` and `push` should only be used when you want to create an exact
> copy of another branch.  It has the effect of flattening out the log,
> so I'd imagine it is a bad idea to "force" through merges that way.

I don't think it is right to see pull as "flattening" the log. That's
what I thought first too, but it is wrong. In particular, in the case
above, it is not possible to get a flat log in bzr (wo using rebase,
that is).

> 
> Do you know whether other systems try to work around this, and how they do it?

git does not have a mainline concept at all. It is just a DAG at both
implementation and UI levels, and the log is just time-sorted as far as
I understand (contrary to bzr where the log is topologically sorted,
which is one of the reason why it is much slower, BTW).

If you look at git output, there is only one indentation, whatever the
branch a commit is coming from. Git does not work around this, because
they don't need to: there is not version in git, just the sha-1 of each
commit. Contrary to version, sha-1 does not have any order concept.

What happens a lot in git is the use of rebase, that is changing the
order of the commits of a branch, to make the history 'nicer'. But you
have to be careful when using rebase because obviously, since you
cut/paste in the DAG, once the branch is published, other people cannot
depend on your branch if you rebase. See for example:

http://kerneltrap.org/Linux/Git_Management

Another solution, albeit with a different purpose, is the patchqueue
concept (loom in bzr, mercurial queues in hg, I don't know in git), but
I still haven't got my head around this one properly to really talk
about it.

> I don't see any history folding as such; I *do* see a log message
> saying that I committed changes from the main branch into the addition
> branch, but those changes *themselves* were not re-merged with
> mainline.

Maybe I don't understand exactly what Fernando meant by history folding,
then. For me, the above log is a typical example of history folding,
because you have two levels of log (one for the mainline, one for the
merged branch).

cheers,

David