From 6dc88cc0dcda3b6654accc15e2b949b340fa4bfd Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Thu, 29 Sep 2005 22:02:11 -0700 Subject: [PATCH] Update 2005-09-29 night. --- Porcelainistas | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ TODO | 12 +++++++----- 2 files changed, 63 insertions(+), 5 deletions(-) create mode 100644 Porcelainistas diff --git a/Porcelainistas b/Porcelainistas new file mode 100644 index 00000000..28c297f3 --- /dev/null +++ b/Porcelainistas @@ -0,0 +1,56 @@ +Message-ID: <20050927001542.GC15615@reactrix.com> +From: Nick Hengeveld +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" +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) , 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 +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: +From: Matthias Urlichs +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. diff --git a/TODO b/TODO index 2ed37daa..86804478 100644 --- a/TODO +++ b/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 -- 2.11.0