git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: What to expect after 0.99.8

From
Junio C Hamano <junkio@cox.net>
Date
Oct 4, 2005, 22:38 UTC
Message-ID
<7v64sc9abr.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<4342F9A4.1090600@citi.umich.edu>
Chuck Lever <cel@citi.umich.edu> 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 <smurf@smurf.noris.de>
    Date: Mon, 03 Oct 2005 22:48:54 +0200
    Message-ID: <pan.2005.10.03.20.48.52.132570@smurf.noris.de>
    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.

Previous: Chuck LeverNext: Fredrik Kuivinen
Message 36 of 39 in “What to expect after 0.99.8”
  1. Junio C HamanoOct 3, 2005
  2. A Large Angry SCMOct 3, 2005
  3. Junio C HamanoOct 3, 2005
  4. Enable and fix support for base less merges.Fredrik Kuivinen, Oct 3, 2005
  5. Josef WeidendorferOct 3, 2005
  6. Junio C HamanoOct 4, 2005
  7. Josef WeidendorferOct 4, 2005
  8. Junio C HamanoOct 4, 2005
  9. Random documentation fixesJonas Fonseca, Oct 3, 2005
  10. Daniel BarkalowOct 3, 2005
  11. Martin CoxallOct 3, 2005
  12. Nick HengeveldOct 3, 2005
  13. Daniel BarkalowOct 3, 2005
  14. Junio C HamanoOct 3, 2005
  15. Daniel BarkalowOct 3, 2005
  16. Junio C HamanoOct 3, 2005
  17. Linus TorvaldsOct 3, 2005
  18. Dan AloniOct 4, 2005
  19. Daniel BarkalowOct 4, 2005
  20. Matthias UrlichsOct 4, 2005
  21. H. Peter AnvinOct 4, 2005
  22. Matthias UrlichsOct 4, 2005
  23. H. Peter AnvinOct 4, 2005
  24. Junio C HamanoOct 4, 2005
  25. Linus TorvaldsOct 5, 2005
  26. H. Peter AnvinOct 5, 2005
  27. Daniel BarkalowOct 4, 2005
  28. H. Peter AnvinOct 4, 2005
  29. Daniel BarkalowOct 4, 2005
  30. Alan ChandlerOct 3, 2005
  31. H. Peter AnvinOct 3, 2005
  32. Greg KHOct 4, 2005
  33. H. Peter AnvinOct 5, 2005
  34. Matthias UrlichsOct 3, 2005
  35. Chuck LeverOct 4, 2005
  36. Junio C HamanoOct 4, 2005
  37. Fredrik KuivinenOct 4, 2005
  38. Fredrik KuivinenOct 5, 2005
  39. Junio C HamanoOct 5, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.