Update 2005-09-29 night.

Porcelainistas

@@ -0,0 +1,56 @@
+Message-ID: <20050927001542.GC15615@reactrix.com>
+From: Nick Hengeveld <nickh@reactrix.com>
+Date: Mon, 26 Sep 2005 17:15:42 -0700
+
+Good point - use of environment variables is more consistent.  Use of
+command-line arguments is a bit more convenient in my case since I'm
+driving the transfer from a perl script, but I suppose consistency is
+more important...
+
+Message-ID: <000a01c5c2fe$71fd6200$0200a8c0@AMEER>
+From: "Ameer Armaly" <ameerarmaly@bellsouth.net>
+Date: Mon, 26 Sep 2005 20:57:33 -0400
+
+I am seriously looking at putting one together in the D language 
+(http://www.digitalmars.com/d) <plug>, though it doesn't actually do 
+anything as of yet, since I have to balance classes along with it.
+
+
+Message-ID: <1127840572.16026.29.camel@mariano>
+From: Mariano Videla <mvidela@ases.com.ar>
+Date: Tue, 27 Sep 2005 14:02:51 -0300
+
+I setup a git repository for gipy... Didn't upload any files in
+sourceforge because I don't think is ready.
+
+http://24.232.198.9:7978/gipy.git
+http://24.232.198.9:7978/cgi/gitweb.cgi
+
+
+Message-ID: <20050928113008.GA11309@snarc.org>
+From: tab@snarc.org (Vincent Hanquez)
+Date: Wed, 28 Sep 2005 13:30:08 +0200
+
+Well, I kinda work on one written in C using a libgit (using exec of git
+executable for the moment) It doesn't do that much at the moment:
+commiting, adding files, removing files.
+
+At some point I'ld like to have a very integrated and easy to use
+porcelain, but for now that's more a learning git by practice kind of
+project.
+
+Message-ID: <pan.2005.09.28.20.22.10.626793@smurf.noris.de>
+From: Matthias Urlichs <smurf@smurf.noris.de>
+Date: Wed, 28 Sep 2005 22:22:13 +0200
+
+Python integration needs either lots of fork+exec, a git rewrite in
+Python, or a libgit reorganization in library-ized C.
+
+I'm doing the latter, but my free time is kindof limited for now.
+
+My library-ize branch is at 
+	git fetch http://netz.smurf.noris.de/git/git.git libize
+if anybody wants to have a look. My first goal is to get object access
+working sanely (because that's what I need for my Python project).
+
+I haven't merged up for some time, though.

TODO

@@ -114,11 +114,12 @@ Technical (heavier)
 Technical (milder)
 ------------------
 
-* Use 'git-update-ref' in the scripts.
+* Use 'git-update-ref' in the scripts [DONE].
 
 * Use symbolic refs in .git/HEAD.  Should we do that everywhere
   while honoring the symlinked HEAD in the existing repositories
   for backward compatibility, or just only when 'ln -s' fails?
+  [DONE].
 
 * Revisit 'git-merge'.  It probably was a mistake to "loop to
   choose the best one", since what is best is not ill defined to
@@ -201,16 +202,17 @@ Technical (milder)
   Either adopt "only the first head is used for the merge by
   default if taken from .git/remotes/ file", or "list heads to
   merge on a separate Merge: line" proposal.  I already have the
-  code to do the former, so...
+  code to do the former, so... [DONE, open for improvement
+  patches but not just suggestions nor complaints.]
 
 
 Technical (trivial)
 -------------------
 
 * Usher SSL enhancements to http-fetch from Nick Hengeveld into
-  a shape acceptable by everybody.
+  a shape acceptable by everybody [DONE].
 
-* Require tk 2.4 in the spec file.
+* Require tk 2.4 in the spec file [DONE].
 
 * show-branch naming heads is buggy [DONE].
 
@@ -218,7 +220,7 @@ Technical (trivial)
 
 * 'git merge-projects'?
 
-* 'git clone' does not check things out.  Should it?
+* 'git clone' does not check things out [DONE].
 
 * 'git lost-and-found'?  Link dangling commits found by
   fsck-objects under $GIT_DIR/refs/lost-found/.  Then