Re: Core and Not-So Core

From: Petr Baudis <pasky@ucw.cz>
Date: May 10, 2005, 23:08 UTC
Message-ID: <20050510230844.GG26384@pasky.ji.cz>
In-Reply-To: <2cfc4032050510160578b81fa7@mail.gmail.com>

Dear diary, on Wed, May 11, 2005 at 01:05:55AM CEST, I got a letter where Jon Seymour <jon.seymour@gmail.com> told me that...

Show 20 quoted lines

> >
> > > I think it would be worthwhile if care was taken to draw a distinction
> > > between the repository and the cache aspects of the git core, perhaps
> > > even going to the extreme of moving all knowledge of the  cache into
> > > cogito itself. By clearly drawing this distinction, we will more
> > > easily enable the creation of different kind of tools sets atop the
> > > foundation of the GIT repository format.
> >
> > I think this is nonsensical. The cache format is tied to the way in which
> > the repository accessing code is written, so a git-core separate from the
> > cache wouldn't have a useful set of code.
> >
> 
> I guess I agree it is somewhat nonsensical if one considers the
> current git toolset as a collection of programs - the exercise now
> might simply reduce to classifying git tools as
> index-using/non-index-using and nothing more. However, it might be
> worth keeping in mind when/if the "libification" of git happens so
> that there is a clean separation of layers in the API between the
> repository API and index/cache/workspace API.

In that case the repository API's input/output is data structure equivalent to the index, and workspace API's input/output is the index too. That is what it really is - and it is kept on the disk only since the commands are invoked separately so it needs to keep the state around somewhere.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor