-----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----- - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html