Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Nov 6, 2006, 16:03 UTC
Message-ID: <46a038f90611060803o653b5b8cx44d3adcfda699ec5@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0611060734490.25218@g5.osdl.org>

On 11/6/06, Linus Torvalds <torvalds@osdl.org> wrote:

Show 8 quoted lines

> On Mon, 6 Nov 2006, Liu Yubao wrote:
> > Then, what bad *logical* problem will happen if a merging that is really a
> > fast forwarding creates a new commit?
> You MUST NOT do that.
>
> If a fast-forward were to do a "merge commit", you'd never get into the
> situation where two people merging each other would really ever get a
> stable result. They'd just keep doing merge commits on top of each other.

Indeed. I used Arch for quite a while and if you were merging between 2 or more repos it would never reach a stable point even if the code didn't change at all.

If a group of 3 developers (with one repor per developer) was developing at a slow pace (say, a daily commit each, plus a couple of pull/updates per day) the garbage-commit to content-commit ratio was awful. If on a given day noone had made a single commit, we'd still have a whole set of useless updates merged and committed.

> Besides, doing an empty commit like that ("I fast forwarded") literally
> doesn't add any true history information.

And as the number of developers and repos grows in a distributed scenarios, fast-forwards increasingly outnumber real commits. The usefulness of your logs sinks to the sewers.

cheers,