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