Re: [RFC] to rebase or not to rebase on linux-next

[Ingo Molnar <mingo@elte.hu>]

* Theodore Tso <tytso@mit.edu> wrote:

> On Mon, Oct 26, 2009 at 07:01:57PM +0100, Stefan Richter wrote:
> > > Suppose I update the 40th patch of a 50th patch series to add check
> > > for kmalloc() returning NULL that had been inadvertently left out, or
> > > some other error checking is added.  Or suppose I add a new tracepoint
> > > definition to a 50 patch series.
> > 
> > ...are bad examples in the context of linux-next, IMO.  A missing
> > allocation failure check or a missing tracepoint don't break
> > bisectability.  So why discard this history?  (It was already published
> > in a release preview.)
> 
> There are multiple issues for rewinding patches.  One is to avoid 
> breaking bisectability.  Other is to keep related changes in 
> functionality in a single place.  2-3 years for now, does anyone 
> really care about retaining development history?  In the human memory, 
> one of the most important parts of long-term memory formation is 
> *forgetting*; that is, editing down everything that happened down to 
> the most cogent and importants bits of history.  This is what is 
> disrupted when people don't get enough sleep.

Fact is that the overwhelming majority of git-rebase uses i've seen were 
not done for ack-adding purposes.

They were used to prettify up a tree shortly before it's pushed 
upstream, and as a happy side-effect to whitewash out the more 
embarrassing bits of the history via backmerges. It presents a rosy 
picture about problem-free development and a perfectly going, fluid 
workflow with perfect foresight, good testing and few mistakes.

A real git tree will contain fixes for brown paperbag bugs, it will 
contain reverts, it will contain the occasional messy changelog. It is 
also, because it's more real life, far more trustable to pull from. The 
thing is, nothing improves a workflow more than public embarrassment - 
but rebasing takes away much of that public embarrassment factor.

Also, i dont buy the bisectability argument either. I bisect all the 
time. The number of bisections i've done on the kernel in the past two 
years are in the hundreds. Still i dont see any actual, frequent 
bisectability problems. (and if i see them i do raise it on lkml)

How come i dont see frequent bisection problems, despite the majority of 
trees and commits (well in excess of 50%) being maintained in 
append-only mode? By your argument i should be seeing an increasing 
amount of bisection problems. In fact i see the opposite: if i see some 
bad bisection bug it is often _due_ to a rebase - a patch was reordered 
without real testing being injected into the new tree, breaking hundreds 
(sometimes thousands) of commits.

So to sum it up - i am sure that there are people who can run nice trees 
responsibly, using just about _any_ source code management tool, be that 
Quilt or stgit. Heck i think Andrew could maintain -mm by scribbling 
patches on tree bark and sending them to Linus via swarms of pigeons. 
But the fundamental fact remains, from all the workflows i tried (and i 
ran 1000+ patches quilt trees just a few years ago), Git append-only 
workflows are the most gradual, most resilient, most scalable, most 
symmetric and hence most trustable source of changes to me.

So it's no wonder Linus mandates all big Git trees to use an append-only 
workflow.

	Ingo