Re: using git directory cache code in darcs?

[Paul Jackson <pj@sgi.com>]

> Not until all the data structures are really really stable.

Fine by me to wait, though perhaps not for the same reason, and perhaps
not as long.

A libgit.so can deal with data structure changes just as well as a set
of command line utilities.  So long as everything funnels through one
place, you can change by changing that one place.

However I am  willing to agree that its not libgit time yet, for two
reasons:

 1) everyone who has two clues on the subject is too busy and
    too productive on more pressing git issues, and

 2) in addition to internal data structures being not yet stable,
    I suspect that the operations (git commands, options and
    behaviour) are also not stable.

The first step of a good libgit is not coding to the internal data
structures, but rather designing the interface (the operations,
arguments, data types, and behaviour).

So, until people have time, and the interface ops are settled down, its
too early to design libgit.  Or at least too early to publish a design
and seek concensus.  If I had the time the first thing I'd be doing
right now would be designing libgit on the side, anticipating the day
when it was time to publish a draft and engage the community discussion
that leads to an adequate concensus.

===

By the way, a good libgit design, in my view, would isolate the data
structures written to files below .git from the data structures
presented at the library API, to some extent.  Changes in the file
structures must be handled without disrupting the library API.

If a libgit API didn't isolate the library caller from details of the
structures in files below .git, then yes you'd want really really stable
data structures, impossibly stable in fact.  That way leads to hacks and
workarounds in the future, because the data structures are never
perfectly stable.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401