On Jul 30, 2007, at 7:42 PM, Linus Torvalds wrote:
On Mon, 30 Jul 2007, Jeff King wrote:
If you followed a strict policy of always merging topics to a "base"
branch as your first parent, then never allowing fast forwards should
allow a very easy-to-read history in gitk.
Only if only *one* person ever does any merges.
Immediately when you have other people merging code, you're now
back in
the same boat.
This is why I personally think the whole policy of "no fast
forward" is
totally broken. It's only usable in a non-distributed environment,
where
there is one central person who does everything (a so-called "star
topology").
I think no fast forward merges can always provide useful information.
Public releases are often created from a public, linear branch that
is not arbitrarily jumping around. Even if more than one person creates
such releases there must be some agreement upon the responsibility for
the release and thus for the branch the releases are created from.
If all agreed to merge topics following the "no fast forward" policy and
to use the release branch as a first parent, the commits along the first
parents would document how commits came into the release branch. Non
fast
forward merges would always document that a series of commits was added
to the release branch at once at the (local time) of the merge commit.
If fast forwards are allowed it depends on whether the release branch
can
be fast-forwarded over a series of commits on a topic branch or not.
In case of fast-forward, the history makes you believe each of the
commits
of the topic branch entered the release branch separately. It hides that
they were all merged at once.
I think, avoiding fast forwards may also be used to document a different
level of quality required from commits to a topic branch and from
commits
to the release branch. A the time of the merge the tip of a topic branch
must fulfill all quality requirements, for example compile on all
platforms
and pass all tests. But this need not be the case for every single
commit
on the topic branch. If you avoid fast forwards you still get a chain of
commits along the first parent that would fulfill your quality
requirements.
If you allowed a fast forward over a low quality topic branch your chain
might be broken and you can't be sure, which commits will have high
quality
and which one have a lower quality.
You may argue that this is all crap because every single commit
should be
of highest quality, but I think this is unrealistic. Especially if
more than
one person is jointly working on a topic branch and less experienced and
more experienced developers work together. It may also be rational to
first
get the basic functionality right and later polish work for several
platforms
and usage scenarios.
Obviously other techniques, like rewriting a topic branch to a
perfect commit
series may be used as well. But from my understanding this may be
hard if more
than a single person is involved. You could also squash the complete
topic
branch into a single commit but then valuable history might get lost.
I don't see why what I have in mind would break if other people are
merging
code, too. They may or may not follow my local rules. But at the time of
merging their changes, I can enforce my local quality policy and
document
this by create a merge commit.
This could even be applied recursively. You could start to do a
couple of
merges but only thoroughly test the final result of the last merge.
You could
then enforce a link between the last very stable commit before you
did all the
merges and the very well tested result after the final merge by
enforcing a
"no fast forward" merge.
I'm not quite sure if such a history would be useful in the long term or
may just become to complex. I'm also not sure if the artificial links
would
cause any trouble. I'm wondering, for example, if there are any cases
in which
the additional links would make branching and merging harder.
Steffen
-
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
