Re: [PATCH] write-tree performance problems

> 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.