Re: [PATCH] write-tree performance problems

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 19, 2005, 23:59 UTC
Message-ID: <Pine.LNX.4.58.0504191651110.6467@ppc970.osdl.org>
In-Reply-To: <Pine.LNX.4.62.0504191629410.26365@qynat.qvtvafvgr.pbz>

On Tue, 19 Apr 2005, David Lang wrote:

Show 5 quoted lines

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

Heh. It's certainly possible. Esepcially with the object sharing, you could create a git archive by just doing a "read-tree" and updating a few files, and you'd never have to even check out the rest of the files at all.

IOW, you can probably set up a new git archive in not much more time than it takes for a "read-tree" + "write-tree", with very little in between. That comes out to about a second, and the write-tree index optimizations would take it down to next to nothing..

However, it definitely wouldn't be useful for _me_. The whole thing that I'm after is to allow painless merging of distributed work. If I have to merge one patch at a time, I'd much rather see people send me patches directly - that's much simpler than having a whole new GIT repository.

So at least to me, a git repository only makes sense when it is a collection of patches.

Does that mean that it wouldn't make sense to others? No. It's really cheap to keep a shared object directory, and have a number of different git archives using that, and you can have ten different trees tracking ten different things, with very little overhead.

But even "cheap" is relative. If you actually want to do _work_ in those repositories, you want to check things out in them, and populate them with files. Even if you do that with hardlinked blobs, just _populating_ the tree itself (setting up the subdirectories and the links) is going to be more expensive than applying a patch in quilt.

		Linus