Re: 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.
>  
>