VCS comparison table
aaron.bentley at utoronto.ca
Tue Oct 17 23:53:34 BST 2006
-----BEGIN PGP SIGNED MESSAGE-----
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:
Say this is the ordering in branch B:
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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v18.104.22.168 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar