Re: merge time

From: Steffen Prohaska <prohaska@zib.de>
Date: Jul 30, 2007, 06:10 UTC
Message-ID: <6FE9FFD6-B5D7-4E1D-A4E8-B6D0E9517503@zib.de>
In-Reply-To: <alpine.LFD.0.999.0707291914451.3442@woody.linux-foundation.org>

On Jul 30, 2007, at 4:29 AM, Linus Torvalds wrote:

Show 17 quoted lines

> So there is never really any way to say that one side of a merge is
> special. The closest you can get is saying
>
>  - the first parent is special.
>
>    This is "see merges from the viewpoint of the merger", but as
>    mentioned, the person who actually did the merge isn't  
> necessarily me,
>    so while this is a totally self-consistent view, it's not really  
> the
>    view you are looking for.
>
>    You can get some of this view by using "git log --first-parent",  
> which
>    basically follows commits preferentially using the first parent,  
> and
>    thus "prefers" history as seen by whoever did the merge.

In general the first parent is not special, agreed. But could one deliberately built a history by following certain rules that make the first parent _always_ a special one?

I think of a quite simple example. Topic branches are always branched off the master, and later merged back. The master, which is the branch an official release is created from, must always be the first parent during a merge. It doesn't matter who does the merges or who does the releases, as long as he follows the rule to start from the last release point and merge in all changes in the appropriate way, such that the first parent rule is followed.

Here are two applications that I think would be interesting:

1) The kernel history. If you went from a current release back
along the first parents you'd see the changes that entered the
official kernel sorted backwards in time. I believe the history of
the kernel is already an approximation of this rule. But maybe I'm
wrong.

2) Developing using topic branches. You start topic branches and
start developing new features. Only later you fix problems on all
supported platforms, polish and review the changes. Not every
commit on the topic branch has the same quality, e.g. the early
commits may not even compile on all supported platforms. But the
tip of the topic branch passes all required tests. After a merge
of the topic branch to a stable branch it would be nice to
distinguish the stable history from the less polished commits on
the topic branch. I think this could be achieved if the first
parent always is linked to a stable commit.

I'm sure some will propose that instead of (2) I should rewrite a topic branch such that every single commit passes all quality requirements. But I strongly believe it is a viable choice not to do so. It may just be too much work and often it's sufficient and easier to polish the tip of a topic branch.

Fast-forward merges would break both of the scenarios. But would they be possible without fast-forward merges?

Would it be possible to ensure that all commits along the first-parent-path have 'release' quality and all release tags are located along this path? What would be the right rules to achieve this objective?

	Steffen