Re: VCS comparison table
- From
Aaron Bentley <aaron.bentley@utoronto.ca>
- Date
- Oct 17, 2006, 22:53 UTC
- Message-ID
- <45355EEE.3060105@utoronto.ca>
- In-Reply-To
- <Pine.LNX.4.64.0610171448150.3962@g5.osdl.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Linus Torvalds wrote:
Show 10 quoted lines
> > 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-----