Re: merge time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux