Core and Not-So Core

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.