Re: [PATCH] write-tree performance problems

On Tue, 19 Apr 2005, Linus Torvalds wrote:

On Tue, 19 Apr 2005, David Lang wrote:

quoted

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.

If so, he should set up one repository per quilt patch.

a tool to do this automaticaly is what I was trying to suggest (and asking 
if it would be useful)

That would be crazy, but yes, it would allow me to cherry-pick which
one(s) I want to merge with.

But the fact is, that cherry-picking should happen at quilt-time not at
git time.

Ok, I could see arguments for both methods. if the forest of disposeable 
repositories is fast enough and flexible enough there is some value of 
getting patches into git as quickly as possible, and not having to fan 
them out to quilt as an intermediate step, but it may not be enough value 
to be worth the added complexity.

not being at all familar with quilt (in fact haveing never seen it, just 
seen it discussed here and LKML), how painful would it be to try and 
implement it useing git as a back-end? you would end up with a bunch of 
extra objects that you will ignore (they are parts of branches that you 
throw away), but I don't know if that space cost (plus the cost of the 
extra trees in git) is going to be too high.

this brings up a thought, is there a way to point at a bunch of 
repositories (trees) and a collection of objects and tell git to purge any 
objects that don't have anything linking to them? in the short-medium term 
this isn't a problem, but in the long term you will have extra objects 
being created and then orphaned when a branch gets thrown away that will 
eventually amount to a noticable amount of space.

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