On Tue, 19 Apr 2005, Linus Torvalds wrote:

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

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.

if you are useing quilt for locally developed patches I fully agree with you, but I was thinking of the case where Andrew is receiving independant patches from lots of people and storing them in quilt for testing, and then sending them on to you. In this case the patches really are independant and it may be useful to continue to treat them this way instead of collapsing them into one 'update from Andrew' feed.

I don't know if this sort of thing happens enough to matter or not.

David Lang

There are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies. And the other way is to make 
it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to