Re: merge time

From: Steffen Prohaska <prohaska@zib.de>
Date: Jul 31, 2007, 18:06 UTC
Message-ID: <9DCA19D8-EDAE-4D04-A8C1-E0FF0A71DC93@zib.de>
In-Reply-To: <alpine.LFD.0.999.0707301038380.4161@woody.linux-foundation.org>

On Jul 30, 2007, at 7:42 PM, Linus Torvalds wrote:

Show 18 quoted lines

> 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