On Tue, 17 Oct 2006, Aaron Bentley wrote:
quoted
quoted
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