VCS comparison table

Aaron Bentley aaron.bentley at utoronto.ca
Tue Oct 17 23:53:34 BST 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus Torvalds wrote:
> 
> On Tue, 17 Oct 2006, Aaron Bentley wrote:
>>>> Interesting.  We don't do 'fast-forward' in that case.
>>> Fast-forward is a really good idea. Perhaps you could implement it,
>>> if it is not hidden under different name?
>> We support it as 'pull', but merge doesn't do it automatically, because
>> we'd rather have merge behave the same all the time, and because 'pull'
>> throws away your local commit ordering.
> 
> Excuse me? What does that "throws away your local commit ordering" mean?

Say this is the ordering in branch A:

a
|
b
|
c

Say this is the ordering in branch B:

a
|
b
|\
d c
|/
e

When A pulls B, it gets the same ordering as B has.  If B did not have e
and c, the pull would fail.

> So generating an extra "merge" commit would be actively wrong, and adds 
> "history" that is not history at all.

It's not a tree change, but it records the fact that one branch merged
the other.

> It also means that if people merge back and forth from each other, you get 
> into an endless loop of useless merge commits.

You can pull if you don't want that.  We haven't found that people are
very fussed about it.

> There's no reason _ever_ to not just fast-forward if one repository is a 
> strict superset of the other.

Maybe not in Git.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFNV7u0F+nu1YWqI0RAhGtAJwOlWpl088pbl63EHyF04qQCYlXBgCfW0Tm
cfXuE0vqeWelfFbpzffiCNI=
=McQ2
-----END PGP SIGNATURE-----




More information about the bazaar mailing list