|| ||Ingo Molnar <mingo-AT-elte.hu> |
|| ||Theodore Tso <tytso-AT-mit.edu>,
Stefan Richter <stefanr-AT-s5r6.in-berlin.de>,
"Luck, Tony" <tony.luck-AT-intel.com>,
Steven Rostedt <rostedt-AT-goodmis.org>,
LKML <linux-kernel-AT-vger.kernel.org |
|| ||Re: [RFC] to rebase or not to rebase on linux-next |
|| ||Wed, 28 Oct 2009 08:26:26 +0100|
|| ||Article, Thread
* Theodore Tso <email@example.com> 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
to post comments)