On Tue, 19 Apr 2005, Linus Torvalds wrote:
On Tue, 19 Apr 2005, David Lang wrote:
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 - 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
