Thread (52 messages) flat view 52 messages, 14 authors, 2016-06-15

Re: [PATCH] write-tree performance problems

From: David Lang <hidden>
Date: 2016-06-15 22:41:53

On Tue, 19 Apr 2005, Linus Torvalds wrote:
On Tue, 19 Apr 2005, David Lang wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help