From: Junio C Hamano Date: Tue, 04 Oct 2005 22:38:48 GMT Subject: Re: What to expect after 0.99.8 Message-ID: <7v64sc9abr.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <4342F9A4.1090600@citi.umich.edu> Chuck Lever writes: > two quick notes: > > 1. git-update-ref has no documentation (i don't have time to sit down > and construct it, otherwise i'd post a patch). Thanks; neither git-symbolic-ref. I'll write them up. > 2. what is your thinking about including the cache abstraction layer > after 1.0 ? i think it would help the libification effort. I haven't had a chance to look at the code Smurf is working on, but I suspect that your cache abstraction work would interact badly with it if done independently and made into mainline first, and would end up requiring some parts of libification to be redone. From: Matthias Urlichs Date: Mon, 03 Oct 2005 22:48:54 +0200 Message-ID: I have started work on doing this "the right way" (as per earlier discussion). Current status: There's a toplevel "struct git_env", an associated "struct git_objdb", and (thread-safe and globals-free) library code to read sha1-identified object (meta)data, including packs and all. http://netz.smurf.noris.de/git/git.git#libize Next on my TODO list: introduce a "struct git_obj" which represents exactly one sha1 and the metadata associated with it, rename the accessor functions to be more consistent, add SWIG interface code and Python testcases, submit to everybody's scrutinity. After that, the task can hopefully be parallelized. Definitely a post-1.0 job; the job is too big, and shipping 1.0 with a partial library that doesn't do much that's useful does not make sense. So if you have energy and inclination, I'd like to see you take a look at the smurf tree, and if you can work with him and add cache abstraction as part of the libification that would be the ideal approach. Then hopefully nobody has to do work twice.