On 1/26/08, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > any particular reason you took this discussion off-list? > No, I am just an idiot. GMail's defualt reply instead of reply-all bites me every friggin time. re-adding the list. > On Sat, 26 Jan 2008, Govind Salinas wrote: > > > On 1/26/08, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > > > > IIRC it was you who started the c# port of git? What happened to it? > > > > Well, that was mostly so I could convince my co-workers to use git (and > > to teach myself C#), but the idea was a non-starter at my company so I > > abandoned it. > > I thought it was a GSoC project? > No, it was my own thing. > > > > 2. Help the libification effort in git so that I can use git code straight > > > > from python. > > > > > > That should also be easy enough; there was a GSoC program, and you could > > > just go there and help that effort, instead of reinventing the wheel. > > > > > > For your convenience: > > > > > > http://repo.or.cz/w/git/libgit-gsoc.git > > > > > > > Yeah, I was looking at that when I was doing Widgit. But last I checked > > there had not been an update in several months, I figured the project > > was dead. > > I should hope that it would make more sense to pick it up than to start a > new project. > Totally agree. > > > > 3. Start stripping away non-performance-critical C code and convert > > > > it to python code to help interoperate with extensions and GUIs > > > > > > I am absolutely no fan of "extensions". You keep breaking other > > > people's code if your core introduces changes; see for example the > > > libgit.a issue with cgit. > > > > The nice thing about extensions is that you don't have to use them if > > you don't want to. > > I know what the nice thing about extensions is. My point was that there > is also a pretty nasty side. One that I am not prepared to accept easily. > There is another benefit too. Have a bit of code that might be dangerous? Put it in an extension and it can be tested in isolation, without the need to rebuild the project (for people that offer to test for you). Once it is ready and tested for general use, it can beincorporated into the standard. > > > > There are 2 main benefits that I am looking for with git > > > > libification. One is, if we can reduce the amount of code that has > > > > to be compiled in C to a small enough subset, we should be able to > > > > build without the need of Cygwin or Msys. > > > > > > This effort would be better helped by converting more scripts to > > > builtins, _not_ by reintroducing the dependency on python. > > > > So a couple of different things here. Firstly, you should not see this > > as introducing a python dependency to git. > > Well, I should hope so. > > > A libified, unified version of git all in C would almost certainly be > > faster than anything done in python, even with the good stuff done in C. > > However, and I know it's a notion that some people don't agree with, I > > believe a small amount of performance (such as overhead from using a > > JITed language) can be sacrificed for ease of development and maintain- > > ability. > > I have no problem with rapid prototyping in shell or perl. But the final > goal has to be C. > > Ciao, > Dscho > > Thanks for the feedback. -Govind - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
