On Sun, 17 Apr 2005, David Roundy wrote:
That's all right. Darcs would only access the cached data through a
git-caching layer, and we've already got an abstraction layer over the
pristine cache. As long as the git layer can quickly retrieve the contents
of a given file, we should be fine.
Yes.
In fact, one of my hopes was that other SCM's could just use the git
plumbing. But then I'd really suggest that you use git itself, not any
libgit. Ie you take _all_ the plumbing as real programs, and instead of
trying to link against individual routines, you'd _script_ it.
In other words, git would be an independent cache of the real SCM,
and/or the old history (ie an SCM that uses git could decide that the
git stuff is fine for archival, and really use git as the base: and then
the SCM could entirely concentrate on _only_ the interesting parts, ie
the actual merging etc).
That was really what I always personally saw git as, just the plumbing
beneath the surface. For example, something like arch, which is based on
patches and tar-balls (I think darcs is similar in that respect), could
use git as a _hell_ of a better history of tar-balls.
The thing is, unless you take the git object database approach, using
_just_ the index part doesn't really mean all that much. Sure, you could
just keep the current objects in the object database, but quite
frankly, there would probably not be a whole lot of point to that. You'd
waste so much time pruning and synchronizing with your real database
that I suspect you'd be better off not using it.
(Or you could prune nightly or something, I guess).
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
