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