Re: [PATCH] write-tree performance problems

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 19, 2005, 22:21 UTC
Message-ID: <Pine.LNX.4.58.0504191514550.2274@ppc970.osdl.org>
In-Reply-To: <Pine.LNX.4.62.0504191508060.26365@qynat.qvtvafvgr.pbz>

On Tue, 19 Apr 2005, David Lang wrote:

> 
> what if you turned the forest of quilt patches into a forest of git trees? 
> (essentially applying each patch against the baseline seperatly) would 
> this make sense or be useful?

It has a certain charm, but the fact is, it gets really messy to sort out later.

The thing is, there's a huge benefit to a straight-line tree: you can do binary searching etc of patches that cause problems, and in general it's just a lot _easier_ to work with a linear set of patches for pretty much everybody.

So yes, it's "cool" to show the fact that patches are independent and show them as each applying to the baseline (and then you can have the "mother of all merges" that ties them all together), but that's just a _nightmare_ when you actually try to debug things and sort things out.

So while I'm a huge proponent of parallell development, and having lots of branches, I actually think that _linearizing_ stuff is a good thing.

So let's put it this way: parallel development and merging is wonderful as a tool to handle true distributed development, and it's the thing that GIT really tries to do. But once you have "local" development (like in a set of quilt patches), the _last_ thing you want to do is try to make it look parallel. You're much better off picking a good order, and sticking with it. Because otherwise, 2 months down the line, you'll just look at that tree, and what you'll want to do is to visualize them linearly anyway.

		Linus