main trunk is at commit X
developer clones Y and adds a patch to it
the merge from Y's tree to the main trunk is a fast-forward
David Lang
On Tue, 31 Jul 2007, Steffen Prohaska wrote:
Date: Tue, 31 Jul 2007 20:06:24 +0200
From: Steffen Prohaska <prohaska@xxxxxx>
To: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Cc: Jeff King <peff@xxxxxxxx>, david@xxxxxxx,
Shawn O. Pearce <spearce@xxxxxxxxxxx>, Junio C Hamano <gitster@xxxxxxxxx>,
Matthew L Foster <mfoster167@xxxxxxxxx>, git@xxxxxxxxxxxxxxx
Subject: Re: merge time
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
