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