Re: using git directory cache code in darcs?

[Linus Torvalds <torvalds@osdl.org>]

On Sat, 16 Apr 2005, David Roundy wrote:
> 
> I've been thinking about the possibility of using the git "current
> directory cache" code in darcs.

Go wild. The license is GPLv2, with the limitation that I really do want
to see v3 before I re-license anything at all, so if you take it into
darcs, you'd need to add that as a per-file comment (I just doing it in
the LICENSE file - I hate cluttering up individual files with tons of
commentary).

> So my questions are:
> 
> 1) Would this actually be a good idea? It seems good to me, but there may
> be other considerations that I haven't thought of.

I really don't know how well the git index file will work with darcs, and 
the main issue is that the index file names the "stable copy" using the 
sha1 hash. If darcs uses something else (and I imagine it does) you'd need 
to do a fair amount of surgery, and I suspect merging changes won't be 
very easy.

So it might well make sense to wait a bit, until the git thing has calmed
down some more. For example, I made some rather large changes
(conceptually, if not in layout of the physical file) to the index file
just yesterday, since git now uses it for merging too.

In git, the index file isn't just a speedup, it's the "work" file _and_
the merge entity. It's not just a floor wax, it's a dessert topping too!

> 2) Will a license be chosen soon for git? Or has one been chosen, and I
> missed it? I can't really include git code in darcs without a license.  I'd
> prefer GPLv2 or later (since that's how darcs is licensed), but as long as
> it's at least compabible with GPLv2, I'll be all right.

Yup, GPL, with the same "v2 by default" that the kernel uses).

> 3) Is it likely that git will switch to not using global variables for
> active_cache, active_nr and active_alloc?

I wouldn't hate it, although for the intent of git, the global approach 
actually makes sense (dammit, I want the basic plumbing to be so small 
that trying to abstract it out more is a waste of time). There's simply 
not a lot of code that should even work at that level.

But if you wait a while, and bide your time, and then spring a clean patch 
on me, I don't see any reason to be difficult about it either.

> 4) Would there be interest in creating a libgit? I've been imagining taking
> git source files and including them directly in darcs' code, but in the
> long run it would be easier if there were a standard git API we could use.

I think libgit might make sense, but again, not quite yet. Maybe the new
merge model was my last smart thought even on the subject of SCM's (I kind
of hope so), but maybe it's not.

My gut _feel_ is that the basic git low-level architecture is done, and
you can certainly start looking around and see if it matches darcs at all. 

			Linus