--- /dev/null
+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.
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
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].
* '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