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? A fast-forward does no such thing. It leaves the local commit ordering alone, it just appends other things on top of it. It's the only sane thing you can do, since the work you merged was already based on your top commit. So generating an extra "merge" commit would be actively wrong, and adds "history" that is not history at all. It also means that if people merge back and forth from each other, you get into an endless loop of useless merge commits. What's the point? They only clutter up the history, and they mean that you can never agree on a common state. There's no reason _ever_ to not just fast-forward if one repository is a strict superset of the other. You must be doing something wrong. Is it just that people want to pee in the snow and leave their mark? Linus - 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