GIT 0.99.9i aka 1.0rc2 is found at usual places.
I think the source-tree-wise almost everything is done except:
 - http-fetch file descriptor leak fix; I tried Nick's

   clean-ups, but haven't tried Pasky's patch yet.  Walt reports

   neither patch fixed the problem.  I wasted the weekend not

   being able to reproduce this myself, until Pasky reminded me

   that I have an old special code in git-clone, which was

   unrelated to this problem, but nevertheless was masking it.
 - Preparation for later dash-less "git frotz" installation

   scheme.  As I said earlier, I intend to do 1.0 with a

   Makefile that installs everything in one directory (either

   $HOME/bin or /usr/bin) by default, but at least we should

   encourage our users to get used to spelling the subcommands

   in dash-less form.  Andreas Ericsson's git wrapper

   implementation was reviewed favourably on the list, and I'd

   like to go with it.
 - archimport update by Eric Wong has not been reviewed yet;

   this is difficult for me since I do not use tla anymore, and

   I am asking help from Martin Langhoff.  I am hoping Eric and

   Martin would come up with an updated patch that satisfies the

   needs of both, at that time the update will happen.

   Personally I do not think 1.0 has to wait for this.
There is a bit of restructuring in the binary packaging for RPM

(and probably Debian side needs matching change as well) before

1.0 can happen.
Anyway, here is the short-log between 0.99.9g and 0.99.9i.

Please give it a good beating.
-- >8 -- cut here -- >8 --
Alex Riesen:

      allow git-update-ref create refs with slashes in names
Andreas Ericsson:

      git-clone: Keep remote names when cloning unless explicitly told not to.

      git-clone: Allow cloning into directories other than child of current dir.

      git-branch: Mention -d and -D in man-page.
Chris Wright:

      specfile cleanups
Fredrik Kuivinen:

      merge-recursive: Indent the output properly

      merge-recursive: Add ...
[ message continues ]

So, you're saying that you have *not* fixed it?  Hm.  Using the

up-to-the-minute repository versions of cogito and git I can now

do a successful clone of the git repository with ulimit -n 64,

which I couldn't do two days ago.  When I get home I'll try it

again on NetBSD also.
-

I just confirmed the good news on NetBSD.  Out of curiosity I did

this test:  I cg-updated and reinstalled cogito, which did *not*

fix the too-many-open-files error.  Then I cg-updated and rebuilt

git which *did* fix the error.  Clearly, something you committed

in the last two days has fixed this problem.  Dunno what you did,

but thanks :o)
-