Core and Not-So Core

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

I have been experimenting with pure-Java implementation of GIT
concepts with a goal of eventually providing plugins to Eclipse to
allow the Eclipse GUI to interact with GIT repositories.

One thing I noticed when doing this is that the present index/cache
structure is rather arbitrary and the optimum index structure is
determined by the structure of the tools that use a GIT repository
rather than the structure of the GIT repository itself.

To give a concrete example: the cache currently contains most of the
posix stat structure primarily to allow quick change detection. In the
Java world, most of the posix stat structure is not directly
accessible via the pure-Java file system abstractions. However, for
most purposes detecting changes to files modification time and file
size would be enough. Given this is the case, a Java-GIT client
doesn't need to bother getting access to a posix stat structure and
could therefore get away with a simpler  index structure, provided it
doesn't need to interoperate with a 'C'-GIT client that shared the
same workspace. A Java-GIT client might also choose to represent an
index cache as a complex serialized Java object graph or (perhaps) an
XML document.

Another example: I can imagine a variant of the index file structure
that recorded all the parents which have been merged into the cache
and automatically include this information when performing the commit.

The point is that many different index file structures are possible
and will be determined in part by the tooling created in the porcelain
layer - there really is no one true index file format as there is a
one true repository format. Different tools can use different index
file formats and still interoperate at the repository level because
only the repository format needs to have a solid, unchanging
definition.

Currently the GIT stack is structured as follows:

cogito
git-core 

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.

e.g., either:

cogito
git-cache
git-respository

or:

cogito-tools
cogito-cache
git-repository

Anyway, I offer this as food for thought - chew or flame away as appropriate!

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