From: david@lang.hm Date: Tue, 31 Jul 2007 20:07:09 GMT Subject: Re: merge time Message-ID: In-Reply-To: <9DCA19D8-EDAE-4D04-A8C1-E0FF0A71DC93@zib.de> 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 > To: Linus Torvalds > Cc: Jeff King , david@lang.hm, > Shawn O. Pearce , Junio C Hamano , > Matthew L Foster , git@vger.kernel.org > 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 > >