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