On 11/6/06, Linus Torvalds <torvalds@xxxxxxxx> wrote:
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,
martin
-
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