Re: Core and Not-So Core

[Jon Seymour <jon.seymour@gmail.com>]

On 5/12/05, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Wed, 11 May 2005, Jon Seymour wrote:
>
> > The repository API would contain functionality equivalent to cat-file,
> > ls-tree, most of fsck-cache, rev-list, rev-tree, diff-tree, most of
> > the transport code - things that don't involve use of the index.
> >
> > The workspace API would contain read-tree, write-tree, commit-tree,
> > etc - things that do involve use of the the index.
>
> Unfortunately for this idea, you can't actually check files into or out of
> the repository using the git tools without the index (in memory at least,
> if not on disk). This is a bit like having a libc with all the system
> calls except read and write. Sure, there are a number of programs that
> would be fine that way, but it makes the API unintuitive, and most serious
> programs need the extension anyway.
>

Daniel,

Checking in/checking out is definitely a workspace API function that
involves an index (almost certainly) an on-disk index, but reading and
writing from and to the repository is purely a repository API
function.

There is no reason why the workspace API can't make use of
"lower-level" functions in the repository API. I guess I would argue
that the repository API really shouldn't need much, if any knowledge,
of the workspace API.

The repository API knows about the on-disk structure of repository
objects - it knows how to write writing compressed, SHA1 signed
objects, it also knows how to pack and unpack the various object types
from their on-disk representation into structures manipulated by the
workspace API.

On the otherhand the workspace API knows about managing index
(workspace) state. It knows how to determine whether the
pre-conditions for a commit have been reached. It knows how to read
the workspace structures and coordinate read and writes from and to
the repository.

I really don't think this makes the API unintuitive, but then I don't
really understand why you think this is the case.

jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com