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.
Git tracks history, not "your view of history". Trying to track "your
view" is fundamentally wrong, because "your wiew" automatically means that
the project history would not be distributed any more - it would be
centralized around what _you_ think happened. That is not a sensible thing
to have in a distributed system.
For example, the way to break the "infinite merges" problem above is to
say that _you_ would be special, and you would do a "fast-forward commit",
and the other side would always just fast-forward without a commit. But
that is very fundamentally against the whole point of being distributed.
Now you're special.
In fact, even for "you", it would be horrible - because you personally
might have 5 different repositories on five different machines. You'd have
to select _which_ machine you want to track. That's simply insane. It's a
totally broken model. (You can even get the same situation with just _one_
repository, by just having five different branches - you have to decide
which one is the "main" branch).
Besides, doing an empty commit like that ("I fast forwarded") literally
doesn't add any true history information. It literally views history not
as history of the _project_, but as the history of just one of the
repositories. And that's wrong.
So just get used to it. You MUST NOT do what you want to do. It's stupid.
If you want to track the history of one particular local branch, use the
"reflog" thing. It allows you to see what one of your local branches
contained at any particular time.
See
[core]
logAllRefUpdates = true
documentation in "man git-update-refs" (and maybe somebody can write more
about it?)
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