Re: [Administrivia] On ruby and contrib/
Johannes Schindelin wrote: Correct. The opinions of inactive community members and non-contributors are less useful. I humbly suggest to treat other people's contribution with the same respect you want yours' to be treated. What?! When did I disrespect other people's contributions? git.git is what it is today because of everyone's contributions: if I disrespected them, why would I work on improving git? My opinion has nothing to do with me, or my contributions. I have already stated multiple times on the list that I take no pride in my contributions whatsoever*: I have no ego to speak of. I said the opinions of inactive community members and non-contributors are less useful [than those of active contributors], and I'm still scratching my head over what you inferred. Do you think that the opinions of inactive community members and non-contributors are _more_ valuable than those of active contributors, or am I missing something? * You'd know that if you read emails on the list. But you don't, for some mysterious unstated reason. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Ramkumar Ramachandra artag...@gmail.com writes: Do you think that the opinions of inactive community members and non-contributors are _more_ valuable than those of active contributors, or am I missing something? I am not Dscho, but it probably is worth saying this anyway. 6d297f81373e (Status update on merge-recursive in C, 2006-07-08) stole merge-recursive.c from git-merge-recursive.py with an explicit purpose of making sure that those without a working Python can perform such a core operation like merge with Git without extra forking. The person who worked on it, as long as he knows that the project not just accepted the patch and kept using the code but also that the project understood the rationale behind that change, does not necessarily have a reason to appear every week to interject comments in discussions on any part of the system, even to proposed changes to merge-recursive.c, as long as the original thing the change meant to address is not broken (e.g. removing merge-recursive.c and add it as a merge strategy written in Python or Ruby might trigger huh, but ditching merge-recursive.c and replacing it with merge-replay.c as long as it works would be a meh for him). When otherwise silent old-timers feel a need to come during a discussion that might affect the course of the project in a major way, we should pay more attention, not less, to what they say (I am not saying we should blindly follow). They can explain why some things are as they are, why some changes that may look like a good idea did not work out and how they failed, etc. Certainly the opinions from them are no less valuable. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen pclo...@gmail.com wrote: On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: Hi Greg, On Thu, 6 Jun 2013, Greg Troxel wrote: As one of the people who helps maintain git packages in pkgsrc, my initial reaction is negative to adding a ruby dependency. My initial reaction, too. It was hard enough to get Perl included with Git for Windows (because of that pesky Subversion dependency). As you can see from the commit history, I was the primary force behind trying to get everything core in Git away from requiring scripting languages (I think it is an awesome thing to provide APIs for as many languages as possible, but a not-so-cool thing to use more than one language in the core code). It does not seem that anybody picked up that task when I left, though. Nobody seems to mention it yet. There's another reason behind the C rewrite effort: fork is costly on Windows. The C rewrite allows us to run with one process (most of the time). This applies for shell, perl and even ruby scripts because libgit.a is never meant to be used outside git.c context (unlike libgit2). In this regard, ruby is just as bad as currently supported non-C languages. Are you sure? --- #!/bin/sh cat /tmp/test EOF require './git' (1..100).each do |e| puts \`git rev-parse HEAD~#{e}\` end EOF strace -o /tmp/log -e fork,clone ruby /tmp/test cat /tmp/log --- --- clone(child_stack=0x7f84131dbff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f84131dc9d0, tls=0x7f84131dc700, child_tidptr=0x7f84131dc9d0) = 17455 +++ exited with 0 +++ --- I wrote a simple Ruby extension to access Git builtins so `git rev-parse` actually calls cmd_rev_parse directly. I don't know of any other language that supports so much extensibility. Of course, as soon as one command does exit(), the script ends too. It could be useful to do experiments though. -- Felipe Contreras #include builtin.h #include cache.h #include fcntl.h #undef NORETURN #undef PATH_SEP #include ruby.h static VALUE shellwords; struct cmd_struct { const char *cmd; int (*fn)(int, const char **, const char *); int option; }; #define RUN_SETUP (1 0) #define RUN_SETUP_GENTLY (1 1) #define USE_PAGER (1 2) #define NEED_WORK_TREE (1 3) static struct cmd_struct commands[] = { { rev-parse, cmd_rev_parse }, { show, cmd_show, RUN_SETUP }, }; static VALUE git_rb_backticks(int o_argc, VALUE *o_argv, VALUE ctx) { int argc, i, old; int pipefd[2]; const char **argv; char buf[0x1000]; VALUE command; int do_read; struct cmd_struct *cmd = NULL; const char *prefix = NULL; if (strncmp(RSTRING_PTR(o_argv[0]), git , 4)) { VALUE port, result; port = rb_funcall(rb_cIO, rb_intern(popen), 1, o_argv[0]); result = rb_funcall(port, rb_intern(read), 0); rb_funcall(result, rb_intern(chomp!), 0); rb_io_close(port); return result; } command = rb_funcall(shellwords, rb_intern(shellsplit), 1, o_argv[0]); rb_ary_shift(command); argc = RARRAY_LEN(command); argv = xcalloc(sizeof(*argv), argc); VALUE *rarray = RARRAY_PTR(command); for (i = 0; i argc; i++) argv[i] = RSTRING_PTR(rarray[i]); old = dup(1); i = pipe(pipefd); dup2(pipefd[1], 1); close(pipefd[1]); for (i = 0; i ARRAY_SIZE(commands); i++) { struct cmd_struct *p = commands[i]; if (strcmp(p-cmd, argv[0])) continue; cmd = p; } if (!cmd) rb_raise(rb_eArgError, unknown command: %s, argv[0]); if (cmd-option RUN_SETUP) prefix = setup_git_directory(); i = cmd-fn(argc, argv, prefix); rb_last_status_set(i, getpid()); fflush(stdout); dup2(old, 1); i = read(pipefd[0], buf, sizeof(buf)); if (buf[i - 1] == '\n') i -= 1; buf[i] = '\0'; return rb_str_new(buf, i); } void Init_git(void) { rb_require(shellwords); shellwords = rb_define_module(Shellwords); rb_define_global_function(`, git_rb_backticks, -1); }
Re: [Administrivia] On ruby and contrib/
On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras felipe.contre...@gmail.com wrote: The reviewer pool for code written in a new language _must_ be seeded by some from the current set of reviewers whose judgement I/we can trust. By that standard nothing will ever change. Ever. Even twenty years from now, you will still only trust people that are familiar with shell, Perl, and C. Because the only way to gain your trust, is by being proficient in shell, Perl, and C. I don't see why a trusted person cannot learn a new language and convince the community to give it a try (well given that enough reviewers support the new language, which was Junio's point). I do. Raise your hand if you are interested in giving a try to Ruby for Git's core given that somebody gives convincing reasons? How many hands do you expect? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Sat, Jun 8, 2013 at 5:08 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras felipe.contre...@gmail.com wrote: The reviewer pool for code written in a new language _must_ be seeded by some from the current set of reviewers whose judgement I/we can trust. By that standard nothing will ever change. Ever. Even twenty years from now, you will still only trust people that are familiar with shell, Perl, and C. Because the only way to gain your trust, is by being proficient in shell, Perl, and C. I don't see why a trusted person cannot learn a new language and convince the community to give it a try (well given that enough reviewers support the new language, which was Junio's point). I do. Raise your hand if you are interested in giving a try to Ruby for Git's core given that somebody gives convincing reasons? Personally, no additional runtime dependency Ruby Python. I don't think Ruby is available on SunOS and I prefer not to build and install Python nor Ruby myself to be able to use Git. So no hands from me. How many hands do you expect? If not many hands show up, the Git community clearly is not ready to adopt Ruby. Maybe ask again next year when Ruby is getting more popular? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen pclo...@gmail.com wrote: On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: Hi Greg, On Thu, 6 Jun 2013, Greg Troxel wrote: As one of the people who helps maintain git packages in pkgsrc, my initial reaction is negative to adding a ruby dependency. My initial reaction, too. It was hard enough to get Perl included with Git for Windows (because of that pesky Subversion dependency). As you can see from the commit history, I was the primary force behind trying to get everything core in Git away from requiring scripting languages (I think it is an awesome thing to provide APIs for as many languages as possible, but a not-so-cool thing to use more than one language in the core code). It does not seem that anybody picked up that task when I left, though. Nobody seems to mention it yet. There's another reason behind the C rewrite effort: fork is costly on Windows. The C rewrite allows us to run with one process (most of the time). This applies for shell, perl and even ruby scripts because libgit.a is never meant to be used outside git.c context (unlike libgit2). In this regard, ruby is just as bad as currently supported non-C languages. Are you sure? I'm not saying you can't. I'm saying it's not meant to be used that way. Which means there may be problems lurking around. You can write a ruby extension to access libgit.a, sure, but how many people on this list understand git design and limits _and_ ruby's good enough to spot the bugs? If a bug is found and requires major restructuring in libgit.a, how are you sure it's worth the effort and does not destablize the rest of git? A better way to do it is linking against libgit2. --- #!/bin/sh cat /tmp/test EOF require './git' (1..100).each do |e| puts \`git rev-parse HEAD~#{e}\` end EOF strace -o /tmp/log -e fork,clone ruby /tmp/test cat /tmp/log --- --- clone(child_stack=0x7f84131dbff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f84131dc9d0, tls=0x7f84131dc700, child_tidptr=0x7f84131dc9d0) = 17455 +++ exited with 0 +++ --- I wrote a simple Ruby extension to access Git builtins so `git rev-parse` actually calls cmd_rev_parse directly. I don't know of any other language that supports so much extensibility. Of course, as soon as one command does exit(), the script ends too. It could be useful to do experiments though. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen pclo...@gmail.com wrote: On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: Hi Greg, On Thu, 6 Jun 2013, Greg Troxel wrote: As one of the people who helps maintain git packages in pkgsrc, my initial reaction is negative to adding a ruby dependency. My initial reaction, too. It was hard enough to get Perl included with Git for Windows (because of that pesky Subversion dependency). As you can see from the commit history, I was the primary force behind trying to get everything core in Git away from requiring scripting languages (I think it is an awesome thing to provide APIs for as many languages as possible, but a not-so-cool thing to use more than one language in the core code). It does not seem that anybody picked up that task when I left, though. Nobody seems to mention it yet. There's another reason behind the C rewrite effort: fork is costly on Windows. The C rewrite allows us to run with one process (most of the time). This applies for shell, perl and even ruby scripts because libgit.a is never meant to be used outside git.c context (unlike libgit2). In this regard, ruby is just as bad as currently supported non-C languages. Are you sure? I'm not saying you can't. I'm saying it's not meant to be used that way. Which means there may be problems lurking around. Code is code. If something is not meant to be used in certain way, you fix it. You can write a ruby extension to access libgit.a, sure, I'm not using libgit.a, I'm using the builtin commands. This is exactly the same code you run when you type 'git foo'. but how many people on this list understand git design and limits _and_ ruby's good enough to spot the bugs? Now you are changing the subject. Does that mean that you accept that 'fork' wouldn't be a problem when writing Ruby scripts? As for the people that know Git and Ruby; they can learn. Didn't you just said that you didn't see any problem with the community learning a new language? If a bug is found and requires major restructuring in libgit.a, how are you sure it's worth the effort and does not destablize the rest of git? There is no need to destabilize anything. I just showed you 100 lines of code that are able to run git commands without forks, and without changing anything in libgit.a. A better way to do it is linking against libgit2. I would rather use what the rest of Git uses. It doesn't make any sense fragment even more the code, and make Ruby scripts 2nd class citizens along the way. Plus, any script that tries to use libgit2, would certainly need more than 100 lines. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Sat, Jun 8, 2013 at 6:20 AM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 5:08 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras felipe.contre...@gmail.com wrote: The reviewer pool for code written in a new language _must_ be seeded by some from the current set of reviewers whose judgement I/we can trust. By that standard nothing will ever change. Ever. Even twenty years from now, you will still only trust people that are familiar with shell, Perl, and C. Because the only way to gain your trust, is by being proficient in shell, Perl, and C. I don't see why a trusted person cannot learn a new language and convince the community to give it a try (well given that enough reviewers support the new language, which was Junio's point). I do. Raise your hand if you are interested in giving a try to Ruby for Git's core given that somebody gives convincing reasons? Personally, no additional runtime dependency Ruby Python. You forgot to list the current ones; shell, perl, python. I don't think Ruby is available on SunOS and I prefer not to build and install Python nor Ruby myself to be able to use Git. So no hands from me. It doesn't surprise me that you stopped at an assumption, instead of making sure. How many hands do you expect? If not many hands show up, the Git community clearly is not ready to adopt Ruby. And they will never be. Nor Ruby nor anything else, which was precisely my point. Maybe ask again next year when Ruby is getting more popular? You will stop again with another assumption, without ever giving it a chance. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen pclo...@gmail.com wrote: On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: Hi Greg, On Thu, 6 Jun 2013, Greg Troxel wrote: As one of the people who helps maintain git packages in pkgsrc, my initial reaction is negative to adding a ruby dependency. My initial reaction, too. It was hard enough to get Perl included with Git for Windows (because of that pesky Subversion dependency). As you can see from the commit history, I was the primary force behind trying to get everything core in Git away from requiring scripting languages (I think it is an awesome thing to provide APIs for as many languages as possible, but a not-so-cool thing to use more than one language in the core code). It does not seem that anybody picked up that task when I left, though. Nobody seems to mention it yet. There's another reason behind the C rewrite effort: fork is costly on Windows. The C rewrite allows us to run with one process (most of the time). This applies for shell, perl and even ruby scripts because libgit.a is never meant to be used outside git.c context (unlike libgit2). In this regard, ruby is just as bad as currently supported non-C languages. Are you sure? I'm not saying you can't. I'm saying it's not meant to be used that way. Which means there may be problems lurking around. Code is code. If something is not meant to be used in certain way, you fix it. Code is code. Bugs can be hard and easy. Hard bugs take a lot of time and may not be worth it after all. You can write a ruby extension to access libgit.a, sure, I'm not using libgit.a, I'm using the builtin commands. This is exactly the same code you run when you type 'git foo'. but how many people on this list understand git design and limits _and_ ruby's good enough to spot the bugs? Now you are changing the subject. Does that mean that you accept that 'fork' wouldn't be a problem when writing Ruby scripts? There are a lot of static variables in builtin/ (and outside too), which make it non-entrant, or at least not safe. fork provides a process space isolation, some depend on that. And there are die() everywhere. Good luck controlling them. As for the people that know Git and Ruby; they can learn. Didn't you just said that you didn't see any problem with the community learning a new language? I said nothing about the community being ready _now_, did I? When you have the support for Ruby in Git, sure go ahead. If a bug is found and requires major restructuring in libgit.a, how are you sure it's worth the effort and does not destablize the rest of git? There is no need to destabilize anything. I just showed you 100 lines of code that are able to run git commands without forks, and without changing anything in libgit.a. And how do you deal with, for example die(), or thread safety? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Sat, Jun 8, 2013 at 7:07 AM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen pclo...@gmail.com wrote: but how many people on this list understand git design and limits _and_ ruby's good enough to spot the bugs? Now you are changing the subject. Does that mean that you accept that 'fork' wouldn't be a problem when writing Ruby scripts? There are a lot of static variables in builtin/ (and outside too), which make it non-entrant, or at least not safe. So? fork provides a process space isolation, some depend on that. Process space isolation from what? And there are die() everywhere. Good luck controlling them. Done. --- a/ruby/git.c +++ b/ruby/git.c @@ -1,6 +1,7 @@ #include builtin.h #include cache.h #include fcntl.h +#include ucontext.h #undef NORETURN #undef PATH_SEP @@ -8,6 +9,8 @@ #include ruby.h static VALUE shellwords; +static ucontext_t main_context; +static int status; struct cmd_struct { const char *cmd; @@ -73,7 +76,14 @@ static VALUE git_rb_backticks(int o_argc, VALUE *o_argv, VALUE ctx) if (cmd-option RUN_SETUP) prefix = setup_git_directory(); - i = cmd-fn(argc, argv, prefix); + getcontext(main_context); + if (status == 0) { + status += 1; + i = cmd-fn(argc, argv, prefix); + } else { + i = 1; + } + status = 0; rb_last_status_set(i, getpid()); fflush(stdout); @@ -87,9 +97,19 @@ static VALUE git_rb_backticks(int o_argc, VALUE *o_argv, VALUE ctx) return rb_str_new(buf, i); } +static void bye(void) +{ + if (status != 1) + return; + status += 1; + setcontext(main_context); +} + void Init_git(void) { rb_require(shellwords); shellwords = rb_define_module(Shellwords); rb_define_global_function(`, git_rb_backticks, -1); + + atexit(bye); } As for the people that know Git and Ruby; they can learn. Didn't you just said that you didn't see any problem with the community learning a new language? I said nothing about the community being ready _now_, did I? If they can learn Ruby five years from now, then can learn it now. When you have the support for Ruby in Git, sure go ahead. You are going in circles. If a bug is found and requires major restructuring in libgit.a, how are you sure it's worth the effort and does not destablize the rest of git? There is no need to destabilize anything. I just showed you 100 lines of code that are able to run git commands without forks, and without changing anything in libgit.a. And how do you deal with, for example die(), or thread safety? See above for die(), and I don't see many perl or shell scripts with multiple threads, why should the Ruby scripts have more than one thread? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Sat, Jun 08, 2013 at 08:20:28AM -0500, Felipe Contreras wrote: There are a lot of static variables in builtin/ (and outside too), which make it non-entrant, or at least not safe. So? fork provides a process space isolation, some depend on that. Process space isolation from what? Manipulation of global variables. Here are a few examples off the top of my head: Try running git diff from your Ruby hook, then try running git diff-files within the same process. I believe the latter will start respecting porcelain diff config like diff.mnemonicprefix. To clear state you need to reset a list of global variables back to their initial states (some of which are the BSS-default zero, but some of which are not). Try running git log followed by another git log. The log family of commands does not clear its marks from the commit objects, since it expects to exit after the traversal. The second log will sometimes give wrong answers if its traversal overlaps with the first (e.g., commits marked SEEN or UNINTERESTING that should not be). You can add a call to clear them at the end of the process, but that does not cover any cases where we die(). These are problems that can be solved. But there is a lot of work involved in finding these subtle bugs and coming up with fixes. I think you would be better off working on an implementation of git that was designed from scratch to work in-process, like libgit2. And it even has an actively developed and maintained Ruby binding[1]. libgit2 doesn't have feature parity with regular git yet, but there are many clients based around it that use the library internally for speed, and then exec regular git to fill in the gaps. -Peff [1] https://github.com/libgit2/rugged -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Sat, Jun 08, 2013 at 12:40:19PM -0500, Felipe Contreras wrote: These are problems that can be solved. But there is a lot of work involved in finding these subtle bugs and coming up with fixes. I think you would be better off working on an implementation of git that was designed from scratch to work in-process, like libgit2. So you are in favor of never ever having an official Git library. Got it. No, I didn't say that at all. I do think that it would be more work to try to slowly massage the git code into a library-ready form than it would be to simply start with more library-friendly code and pull in bits of git.git as appropriate. That is what the libgit2 project is doing. Perhaps one day that project will reach a point where we start building git.git commands off of it or sometihng like it (for that matter, there is no reason you could not build external commands off of libgit2 right now). Would it be the official Git library then? I don't know. It is not clear to me what that even means. In the meantime, I think it cannot be a bad thing for libgit2 to proceed along its path, and I don't see a good reason for people not to use it. But hey, you don't need to listen to me. If you think it would be easier to make the git.git code into a library, go ahead and work on it. But I think you will find that there are a large number of hard-to-find bugs caused by implicit assumptions about global state, how file descriptors are used, and so forth. There's a reason why the Git project doesn't use libgit2, and for the same reason the official Ruby scripts should not use it. What reason is that? As history indicates, the Git project will never have any pressure to fix it's re-entrancy and re-run issues, so these issues will remain there forever. Only if you allow code that exposes those issues will there ever be any pressure to fix them. I think it is a matter of critical mass. If you were to start linking against libgit.a and 90% of it worked, you might have a reason to fix the other 10%. But I suspect it is more the other way around. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Sat, Jun 8, 2013 at 7:10 PM, Jeff King p...@peff.net wrote: On Sat, Jun 08, 2013 at 12:40:19PM -0500, Felipe Contreras wrote: These are problems that can be solved. But there is a lot of work involved in finding these subtle bugs and coming up with fixes. I think you would be better off working on an implementation of git that was designed from scratch to work in-process, like libgit2. So you are in favor of never ever having an official Git library. Got it. No, I didn't say that at all. Then you truly think libgit2 will ever reach the point where it can replace libgit.a? It won't. But decreeing that both projects should remain isolated, and that libgit.a should never be a library, you are effectively condemning the effort to fail, knowingly or not. How many years has libgit2 been brewing? Do you think it's closer for merging so it can be used by Git's core? No, it doesn't, and it will not in the future, because it was never meant for that. I do think that it would be more work to try to slowly massage the git code into a library-ready form than it would be to simply start with more library-friendly code and pull in bits of git.git as appropriate. It might be more effort, but the results are guaranteed by our extensive testing infrastructure and huge user-base. Slowly but steadily we'll get there. Waiting for libgit2 to switch directions and reach some hypothetical point is waiting for hell to freeze. It won't happen. There's no incentive nor reason for it to happen. That is what the libgit2 project is doing. Perhaps one day that project will reach a point where we start building git.git commands off of it or sometihng like it (for that matter, there is no reason you could not build external commands off of libgit2 right now). Would it be the official Git library then? I don't know. It is not clear to me what that even means. It means 'make install' installs a shared library with a clearly defined and stable API that other projects can depend on, and it can be used for all sort of purposes, including the git binary, and it's builtins. In the meantime, I think it cannot be a bad thing for libgit2 to proceed along its path, and I don't see a good reason for people not to use it. Its path will never end as an official Git library, not unless we do something. But hey, you don't need to listen to me. If you think it would be easier to make the git.git code into a library, go ahead and work on it. But I think you will find that there are a large number of hard-to-find bugs caused by implicit assumptions about global state, how file descriptors are used, and so forth. That's impossible. Specially since moving irrelevant code out of libgit.a is not permitted. There's a reason why the Git project doesn't use libgit2, and for the same reason the official Ruby scripts should not use it. What reason is that? You tell me. Why isn't Git using libgit2? As history indicates, the Git project will never have any pressure to fix it's re-entrancy and re-run issues, so these issues will remain there forever. Only if you allow code that exposes those issues will there ever be any pressure to fix them. I think it is a matter of critical mass. If you were to start linking against libgit.a and 90% of it worked, you might have a reason to fix the other 10%. But I suspect it is more the other way around. It doesn't matter if it's 90% or 10%, it's the only thing we have. Unless you are in favor of including libgit2 and start using it for Git's core *right now*, the only way forward is to improve libgit.a. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Sat, Jun 08, 2013 at 08:17:08PM -0500, Felipe Contreras wrote: No, I didn't say that at all. Then you truly think libgit2 will ever reach the point where it can replace libgit.a? I don't know. It may. Or something like it may. It is certainly not ready to do so yet, but perhaps one day it will be. It won't. Oh, I see, you were not actually interested in my answer and were just being rhetorical. But decreeing that both projects should remain isolated, and that libgit.a should never be a library, you are effectively condemning the effort to fail, knowingly or not. Huh? When did I decree anything? You asked Duy what kinds of problems you would run into with running multiple git commands in the same process space. I answered with concrete examples, and gave my opinions on what the path of least work would be to reach a re-entrant library. You don't have to agree (didn't I even say you don't have to listen to me in the last email?). How many years has libgit2 been brewing? Do you think it's closer for merging so it can be used by Git's core? No, it doesn't, and it will not in the future, because it was never meant for that. There has been about 2 years of active development, and there's been quite a lot of improvement in that time. Closer than what? Than it was 2 years ago? Yes, I think it is. But it still has a ways to go. I do not think there will be a flag day where we throw away git.git's code and start using libgit2. But we could slowly start replacing underlying bits with libgit2 bits, if that implementation proves to be robust and clean enough to do so. But hey, you don't need to listen to me. If you think it would be easier to make the git.git code into a library, go ahead and work on it. But I think you will find that there are a large number of hard-to-find bugs caused by implicit assumptions about global state, how file descriptors are used, and so forth. That's impossible. Specially since moving irrelevant code out of libgit.a is not permitted. I'm not even sure what your second sentence means. But it seems to me that the first step would be cleaning up the internal code so that it is more friendly to library callers (both in interface and in being re-entrant), with those first sets of callers being the existing code in git.git. Such cleanups would be a good thing for the modularity of the code, even without an intended library step. And then you can start to pull out individual interfaces that are known to be safe for library use, and think about making a coherent library out of them. And please don't tell me about not permitted. You are free to fork and work on this. But do not expect people who have already said that does not seem like a fruitful path to me to jump into it with you. If you think it is worth doing and that you can come up with initial results to convince others, go for it. There's a reason why the Git project doesn't use libgit2, and for the same reason the official Ruby scripts should not use it. What reason is that? You tell me. Why isn't Git using libgit2? Wait, you indicated you had such a reason in mind, but now you won't tell me? Is it a secret? I think it is a matter of critical mass. If you were to start linking against libgit.a and 90% of it worked, you might have a reason to fix the other 10%. But I suspect it is more the other way around. It doesn't matter if it's 90% or 10%, it's the only thing we have. Unless you are in favor of including libgit2 and start using it for Git's core *right now*, the only way forward is to improve libgit.a. That seems like a false choice to me. You obviously feel that libgit2 is some kind of dead end. I don't agree. Whatever. I have very little interest in discussing this further with you, as it is not leading in a productive direction. In my opinion, the productive things to do would be one (or both) of: 1. Work on libgit2. 2. Clean up non-reentrant bits of git.git, hopefully making the code more readable and more modular (and taking care not to make it worse in other ways, like maintainability or performance). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Sat, Jun 8, 2013 at 9:23 PM, Jeff King p...@peff.net wrote: On Sat, Jun 08, 2013 at 08:17:08PM -0500, Felipe Contreras wrote: No, I didn't say that at all. Then you truly think libgit2 will ever reach the point where it can replace libgit.a? I don't know. It may. Or something like it may. It is certainly not ready to do so yet, but perhaps one day it will be. Perhaps one day we would end poverty and hunger, and perhaps one day we will live in peace, but I wouldn't hold on my breath. I fact, I'll do the opposite, I bet it won't happen anytime soon. It won't. Oh, I see, you were not actually interested in my answer and were just being rhetorical. But decreeing that both projects should remain isolated, and that libgit.a should never be a library, you are effectively condemning the effort to fail, knowingly or not. Huh? When did I decree anything? When you said in your opinion we should wait until libgit2 is ready, and not improve libgit.a. How many years has libgit2 been brewing? Do you think it's closer for merging so it can be used by Git's core? No, it doesn't, and it will not in the future, because it was never meant for that. There has been about 2 years of active development, and there's been quite a lot of improvement in that time. Closer than what? Than it was 2 years ago? Yes, I think it is. But it still has a ways to go. Why is it closer? In what ways is it a better fit now than 2 years ago? What is missing before merging to be used in Git's core? I do not think there will be a flag day where we throw away git.git's code and start using libgit2. But we could slowly start replacing underlying bits with libgit2 bits, if that implementation proves to be robust and clean enough to do so. And what are we waiting for then? Shouldn't we copy the whole libgit2 code and start migrating? But hey, you don't need to listen to me. If you think it would be easier to make the git.git code into a library, go ahead and work on it. But I think you will find that there are a large number of hard-to-find bugs caused by implicit assumptions about global state, how file descriptors are used, and so forth. That's impossible. Specially since moving irrelevant code out of libgit.a is not permitted. I'm not even sure what your second sentence means. It means this: http://article.gmane.org/gmane.comp.version-control.git/226752 I move code that doesn't belong in a libgit library out of libgit.a, and the change gets rejected. But it seems to me that the first step would be cleaning up the internal code so that it is more friendly to library callers (both in interface and in being re-entrant), That is the second step. It doesn't make sense to make code re-entrant, if that code will only be used by builtin commands. First step is to move irrelevant code out of libgit.a. There's a reason why the Git project doesn't use libgit2, and for the same reason the official Ruby scripts should not use it. What reason is that? You tell me. Why isn't Git using libgit2? Wait, you indicated you had such a reason in mind, but now you won't tell me? Is it a secret? I did not. I made the assumption that there was a reason, if there's no reason to stay clear of libgit2, then let's merge it already. I think it is a matter of critical mass. If you were to start linking against libgit.a and 90% of it worked, you might have a reason to fix the other 10%. But I suspect it is more the other way around. It doesn't matter if it's 90% or 10%, it's the only thing we have. Unless you are in favor of including libgit2 and start using it for Git's core *right now*, the only way forward is to improve libgit.a. That seems like a false choice to me. You obviously feel that libgit2 is some kind of dead end. I don't agree. Whatever. I never said so. It is a dead end *if* we don't do an effort to have a proper libgit library, which is the path we are taking. I have very little interest in discussing this further with you, as it is not leading in a productive direction. In my opinion, the productive things to do would be one (or both) of: 1. Work on libgit2. 2. Clean up non-reentrant bits of git.git, hopefully making the code more readable and more modular (and taking care not to make it worse in other ways, like maintainability or performance). You forgot the first step of 2.: move irrelevant code out of libgit.a. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Hi Ram, On Sat, 8 Jun 2013, Ramkumar Ramachandra wrote: Felipe Contreras wrote: Also we heard from no regular/high-value reviewers that they feel comfortable reviewing additions in Ruby. Correction; *current* regular/high-value reviewers. Correct. The opinions of inactive community members and non-contributors are less useful. I humbly suggest to treat other people's contribution with the same respect you want yours' to be treated. Just a suggestion, J -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Hi Ram, On Sat, 8 Jun 2013, Ramkumar Ramachandra wrote: Felipe Contreras wrote: While at it, why not re-evaluate the whole msysgit approach? I bet we don't need a whole separate project just to create a Windows installer. I've written Windows installers before, it's very easy to do from Linux. Yeah, taking the pain out of msysgit packaging would be a great way to counter this new-dependency-fud. The main problem, as mm pointed out is subversion + perlxs. Yeah, this is the main problem, and you probably will end up with a much better (Linux-based) solution than the people who contributed to the Git for Windows project in all those years since August 2007. Surprise me, with code, J -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Hi Duy, On Sat, 8 Jun 2013, Duy Nguyen wrote: On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: Hi Greg, On Thu, 6 Jun 2013, Greg Troxel wrote: As one of the people who helps maintain git packages in pkgsrc, my initial reaction is negative to adding a ruby dependency. My initial reaction, too. It was hard enough to get Perl included with Git for Windows (because of that pesky Subversion dependency). As you can see from the commit history, I was the primary force behind trying to get everything core in Git away from requiring scripting languages (I think it is an awesome thing to provide APIs for as many languages as possible, but a not-so-cool thing to use more than one language in the core code). It does not seem that anybody picked up that task when I left, though. Nobody seems to mention it yet. There's another reason behind the C rewrite effort: fork is costly on Windows. The C rewrite allows us to run with one process (most of the time). This applies for shell, perl and even ruby scripts because libgit.a is never meant to be used outside git.c context (unlike libgit2). In this regard, ruby is just as bad as currently supported non-C languages. I think you should have said on Windows when you said fork is costly. Oh wait, you did. It seems that at least some people participating in this discussion are not overly keen on supporting the platform that -- according to statistics, i.e. facts -- is the most prevalent. I am glad that Junio still seems to be interested in giving us poor folks trying to make the Git experience on Windows a less sucky one enough credit, even if we only got a little over 900 commits into git.git. But that does not count because the commits are older than one year. That makes them useless to some people, apparently. Hopefully Junio will have more mercy on us poor Windows folks than others would, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
David Lang wrote: Well, Felipe is saying that Perl is dieing and we should re-write everything that exists in Perl to Ruby. I don't agree with that opinion. More generally, I think the entire discussion on what _should_ or _should not_ be done is rubbish. What _will_ and _will not_ happen depends on the patches contributors send. If a contributor sends a patch rewriting git-svn in ruby, then we have a discussion: is anyone bored enough to pick up the task in the first place? TIOBE index graph is press coverage as far as I'm concerned. Well, that's your definition of press coverage then. TIOBE index is generated from scraping the web to figure out which languages are living, based on discussions between programmers (and yes, press articles). I do not have conclusive or undeniable proof that perl is dying, but the trends are indicative of a decline. I think Felipe is using the argument that perl is declining to answer the question why didn't you write git-related in perl instead?; that's it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Junio C Hamano wrote: So at least for now, the conclusion is to take approach #1, i.e. somebody who finds related a good addition rewrites it in Perl to promote it out of contrib/ once the design issues settle (of course it is still a possibility that no such volunteer appears). We'll think about it if and when we get major ruby patches, and see perl patches declining. One git-related.rb doesn't say anything. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Matthieu Moy matthieu@grenoble-inp.fr writes: * Ask the user to build external programs with make GIT_ROOT=where/git/lives/ * or, ask users to checkout the external program as a subdirectory of git.git to build it (for example, clang's build installation ask you to put clang as a subdirectory of LLVM's tree). But my main point is that I think it would be easier to phase out contrib/ if there were a good alternate way of providing visibility to satellite projects. [...] Perhaps ranking the tools based on the results of the Git user surveys would help bring the most popular to the top of each category. I think this is the most important point. A good example would be git-multimail: for now, the shell version in contrib/ is somehow considered as the official hook to send emails, just because it is in contrib, while git-multimail is clearly superior (unless you don't have a python interpreter on your server). I was envisioning to sift what are in contrib/ into these four categories: (1) Ones that deserve to be Git subcommands; (2) Ones that are useful only in the context of using Git (e.g. hooks, completion scripts, credential and remote helpers); (3) Ones that are no longer useful; (4) Ones that primarily _use_ Git, not the other way around (i.e. opposite of category (2) which help use of Git). The first category will live next to git-am.sh (i.e. in the longer term when we restructure the source tree into src/, lib/, etc., candidates for new scripted subcommands move with the scripted Porcelains). The second category will be in a separate hierarchy (perhaps addons/, hooks/, ..., but I am fine if we decide to keep them in contrib/addons, contrib/hooks, etc.). The last two categories will be removed; people are welcome to decide which category between (3) and (4) each piece belongs to, and pick up to start a standalone third-party project. The multimail tool can be in the second category. It helps use of Git more than it is helped by using Git. I'm not opposed to Junio's proposal to restrict contrib/ (although a bit reluctant), but I think this should be done with care, at least to give potential users a way to chose which tool to use (really, nobody want to go use https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools to pick the right tool. It's a great list, but not a guide). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Matthieu Moy wrote: Reading Git for Windows's FAQ ( https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions ), it seems rather clear that the TODO-list is already long to have a correct Perl support (I'm quite admirative of the work done already). The POSIX guys shouldn't move faster than the Windows guys can follow. Ha! So, it's subversion and perlxs. I was wondering what was so non-trivial about shipping a perl interpreter with Windows when dscho mentioned it. Hopefully, I've done a little bit to improve the situation by pushing svnrdump into core (I don't know if it has any users). On the git side, git-remote-testsvn is still a toy (which is a product of many months of work by db + 2x SoCs) compared to git-svn.perl. Yeah, supporting subversion is extraordinarily painful. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Matthieu Moy wrote: I think it should be the Git for Windows community, and my feeling is that the community developing Git for POSIX systems is far more active than the one making it work for Windows (although we may now have more windows users than unix users). If I can be excused for being frank, and saying something potentially blasphemous: I think he way forward on Windows is an implementation like libgit2 or git# with some sort of gui/ide integration. I never understood why users on Windows want to use something as POSIX'y as git.git. Wouldn't they prefer some visual-studio integration thing? *scratches head* -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Matthieu Moy matthieu@grenoble-inp.fr writes: The POSIX guys shouldn't move faster than the Windows guys can follow. That is a very good summary. It does not mean everybody must always crawl at the same pace as the slowest people. But it is one of the important things we should consider, when we have choices to make (e.g. do we write this in Python, do we write it using this Perl module we haven't depended on, etc.), to pick the one that does not make others work harder than necessary---it affects the trade-offs. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Ramkumar Ramachandra artag...@gmail.com writes: I think he way forward on Windows is an implementation like libgit2 or git# with some sort of gui/ide integration. I never understood why users on Windows want to use something as POSIX'y as git.git. Whether it's based on POSIX is an implementation detail for the user. The real question is more command-line Vs GUI than POSIX/Win32. Some Linux users like GUI, some windows users use command-line. I tried IDE integration with EGIT, and quite frankly I ended-up doing all the Git stuff in a terminal next to Eclipse. Wouldn't they prefer some visual-studio integration thing? *scratches head* Visual Studio now has official Git support from MS (based on libgit2 if I understood correctly). That's cool, but not a reason to kill msysgit IMHO ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Matthieu Moy wrote: Visual Studio now has official Git support from MS (based on libgit2 if I understood correctly). That's cool, but not a reason to kill msysgit IMHO ;-). Oh, I'm not interested in killing anything. If people want msysgit, they will work on it: I'm nobody to say otherwise. I was just curious to know why msysgit is suffering from a lack of attention: fewer users? Whether it's based on POSIX is an implementation detail for the user. The real question is more command-line Vs GUI than POSIX/Win32. Some Linux users like GUI, some windows users use command-line. I tried IDE integration with EGIT, and quite frankly I ended-up doing all the Git stuff in a terminal next to Eclipse. I see. But isn't it possible to implement a CLI in libgit2 too, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Jonathan Nieder wrote: Ramkumar Ramachandra wrote: I think he way forward on Windows is Why is there only one way forward? Why do you get to pick it, given that you've said you're not interested in working on it? [...] I never understood why users on Windows want to use something as POSIX'y as git.git. Plenty of users on Windows use a command line. I have even been such a user from time to time. I'm quite grateful for Dscho et al's work on making that less painful. Jonathan I agree completely. It's rare that I use Windows now, but a few years ago I installed Cygwin on any machine that I would use in any serious capacity. I haven't needed to do this since I started to use Git; the Windows installer ships all of the POSIX utilities that I need (with the possible exception of 'tree', and the caveat that scp can't handle files = 2GB). I'm very appreciative of the work that's gone in to Git for Windows, and from my perspective it's a pleasant coincidence that it includes a POSIX shell and associated tools. MMR... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Ramkumar Ramachandra artag...@gmail.com writes: Whether it's based on POSIX is an implementation detail for the user. The real question is more command-line Vs GUI than POSIX/Win32. Some Linux users like GUI, some windows users use command-line. I tried IDE integration with EGIT, and quite frankly I ended-up doing all the Git stuff in a terminal next to Eclipse. I see. But isn't it possible to implement a CLI in libgit2 too, no? Yes (there have actually been several attempts at this like https://github.com/Romain-Geissler/git2 and https://github.com/vfr-nl/git2/), but there are a *lot* of stuff that are in git.git and not in libgit2. I'd love to see Git re-implemented on top of libgit2, but that's not going to happen tomorrow :-\. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Fri, Jun 7, 2013 at 10:20 AM, Junio C Hamano gits...@pobox.com wrote: Ramkumar Ramachandra artag...@gmail.com writes: I think Felipe is using the argument that perl is declining to answer the question why didn't you write git-related in perl instead?; that's it. A question which nobody asked, I presume? I think we heard enough from packaging folks that a new dependency is unwelcome. What are you talking about? Which are these packaging folks we heard from? Also we heard from no regular/high-value reviewers that they feel comfortable reviewing additions in Ruby. Correction; *current* regular/high-value reviewers. So at least for now, the conclusion is to take approach #1, i.e. somebody who finds related a good addition rewrites it in Perl to promote it out of contrib/ once the design issues settle (of course it is still a possibility that no such volunteer appears). Regardless of what you conclude, Perl still continues to die, and by clinging to a dying language, all we do is hurt the project. There's tons of people that are familiar with Git and Ruby, but these people are not in this mailing list because there's nothing for them to discuss, because Git doesn't use Ruby. By making conclusions based on the comments from people who do follow the mailing list *currently*, you are being biased towards the status quo. It's no surprise that you decided to keep the status quo. We could change, and we would probably receive a big influx of fresh contributors happy that they can contribute in their favorite language. But we won't do that, why? Because you already decided that's not going to happen, because you are making the false assumption that things in the future can only be like things have been in the past. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Fri, Jun 7, 2013 at 2:00 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Ramkumar Ramachandra artag...@gmail.com writes: Whether it's based on POSIX is an implementation detail for the user. The real question is more command-line Vs GUI than POSIX/Win32. Some Linux users like GUI, some windows users use command-line. I tried IDE integration with EGIT, and quite frankly I ended-up doing all the Git stuff in a terminal next to Eclipse. I see. But isn't it possible to implement a CLI in libgit2 too, no? Yes (there have actually been several attempts at this like https://github.com/Romain-Geissler/git2 and https://github.com/vfr-nl/git2/), but there are a *lot* of stuff that are in git.git and not in libgit2. I'd love to see Git re-implemented on top of libgit2, but that's not going to happen tomorrow :-\. Specially not if we *always* keep the status quo, and don't make better use of C and scripting languages. One of the advantages of Ruby is that it can be very easily extended from C. I have never seen an easier way to write bindings than in Ruby. If we allowed Ruby to be in the core, it would make sense to create official Ruby bindings, and that would create an enormous motivation for libigit/libgit2 to be complete. But if we always keep the status quo, there will never be that much motivation for such an effort. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 10:25 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote: Johannes Schindelin wrote: My initial reaction, too. It was hard enough to get Perl included with Git for Windows (because of that pesky Subversion dependency). Nevertheless, we had to do it, and we did it. That is not quite correct. *I* did it. Not *we*. And I will not do it again. That's fine, I can do it. I bet it will be easy. While at it, why not re-evaluate the whole msysgit approach? I bet we don't need a whole separate project just to create a Windows installer. I've written Windows installers before, it's very easy to do from Linux. Rewriting everything in C? Is anyone bored enough to pick up this task? Bourne shell is a great language for prototyping; git-rebase.sh (and friends), git-stash.sh, git-pull.sh are doing just fine. Sure, it makes sense to do heavy-lifting in C, and this is happening as it has always been happening (remember git-commit.sh?). If you followed the list emails, you'd know that Felipe is looking into delegating large portions of the work done by git-rebase.sh to sequencer.c. As you know, there are very good reasons why I do not follow those mails. To the detriment on the project. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 3:19 PM, David Lang da...@lang.hm wrote: On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote: David Lang wrote: Perl use may or may not be declining (depending on how you measure it), but are you really willing to take on the task of re-writing everything that's in Perl into another language and force all developers of scripts to learn that other language? what's the ROI of this? Let's not talk hypotheticals. git-svn.perl (+ perl/SVN/*.pl) is absolutely massive. It's an incredibly useful tool in that it actually works, and that there is nothing replacing it in the foreseeable future. This monster was written almost entirely by one brilliant person, and nobody is going to rewrite it. We don't start a huge discussion about what languages are approved before accepting such a contribution: if the contributor wants to write something in a dominant language (Perl in this case), and it's going to be useful, we merge it. End of story. Well, Felipe is saying that Perl is dieing and we should re-write everything that exists in Perl to Ruby. No, I said we should try to move away from Perl. Move stuff to C, shell scripts, and yeah, Ruby. Why are we discussing something that is indeterminate? It is impossible to foresee the future, but that is no reason to freeze _present_ development. and it's not a reason to throw away existing stuff based on the argument that Perl is dieing Who said anything about throwing away code? Nobody claimed that press coverage is a good metric. We can only talk about facts, and Felipe already showed you a TIOBE index graph. If you have overwhelming _evidence_ that Ruby is a weak language that will die soon, share it: otherwise, I see no value in this discussion. TIOBE index graph is press coverage as far as I'm concerned. I'm not saying that Ruby in particular has a fatal flaw, I'm just questioning the Perl is dead, re-write everything in Ruby mantra. The language that you choose to use when writing a new application is related to things related to that type of application. Ruby is not an extremely common language for sysadmins to use. Who said we need a language commonly used by sysadmins for our Git core? Perl remains a common language for these sorts of tasks, even if it's not used for user visible applications. Ruby is pretty much a replacement for Perl. For every task Perl is good, Ruby also is. Ruby's syntax even borrows from Perl. The difference is; Ruby is better for many more tasks that suck in Perl. Arguing that Perl is dieing, we need to abandon it is just wrong. Straw man. Nobody is arguing that. I said we should try to avoid it, not abandon it immediately. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Felipe Contreras wrote: While at it, why not re-evaluate the whole msysgit approach? I bet we don't need a whole separate project just to create a Windows installer. I've written Windows installers before, it's very easy to do from Linux. Yeah, taking the pain out of msysgit packaging would be a great way to counter this new-dependency-fud. The main problem, as mm pointed out is subversion + perlxs [1]. Any idea how to tackle that? [1]: https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Ramkumar Ramachandra wrote: commit a lot of good ruby code to contrib* Oh, by the way: I have a project idea. There's this really popular project called hub[1] that has an implementation of the GitHub API in ruby. Unfortunately, it's a terrible piece of software because it creates an extra layer of indirection by putting a ruby wrapper on top of git, and this slows git down: I cannot tolerate even a microsecond of delay in git. Maybe it's worth ripping out the GitHub API implementation and writing some useful subcommands? [1]: https://github.com/defunkt/hub -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Felipe Contreras felipe.contre...@gmail.com writes: I think we heard enough from packaging folks that a new dependency is unwelcome. What are you talking about? Which are these packaging folks we heard from? Dscho is one of the primary people behind msysgit effort, and I consulted with others from the circle with an draft before I sent the message to the list for sanity checking (fearing that I may be worrying about adding new dependencies needlessly). Jonathan packages git for Debian and he is negative on adding new dependency needlessly. It was unexpected that we hear from a pkgsrc person but the response was also negative. Also we heard from no regular/high-value reviewers that they feel comfortable reviewing additions in Ruby. Correction; *current* regular/high-value reviewers. That is exactly what I meant. The code review is not only about following best practices in the implementation language. If somebody who is an expert in a language we do not currently depend on, but who does not know how the parts of Git are supposed to fit together enough to judge the soundness of the design of new code written in that new language, or does not know how the tests, documentation and log messages are supposed to written around here, that person cannot be the only reviewer for changes written in that language to ensure quality standard. The reviewer pool for code written in a new language _must_ be seeded by some from the current set of reviewers whose judgement I/we can trust. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Fri, Jun 7, 2013 at 2:55 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: I think we heard enough from packaging folks that a new dependency is unwelcome. What are you talking about? Which are these packaging folks we heard from? Dscho is one of the primary people behind msysgit effort, and I consulted with others from the circle with an draft before I sent the message to the list for sanity checking (fearing that I may be worrying about adding new dependencies needlessly). He said he won't do it, but I said I would. Doesn't that solve the problem? Jonathan packages git for Debian and he is negative on adding new dependency needlessly. I don't see any comment from Jonathan. It was unexpected that we hear from a pkgsrc person but the response was also negative. You mean Greg Troxel? He is only one of the persons that help, and I did shut down his argument, didn't I? Also we heard from no regular/high-value reviewers that they feel comfortable reviewing additions in Ruby. Correction; *current* regular/high-value reviewers. That is exactly what I meant. The code review is not only about following best practices in the implementation language. If somebody who is an expert in a language we do not currently depend on, but who does not know how the parts of Git are supposed to fit together enough to judge the soundness of the design of new code written in that new language, or does not know how the tests, documentation and log messages are supposed to written around here, that person cannot be the only reviewer for changes written in that language to ensure quality standard. The reviewer pool for code written in a new language _must_ be seeded by some from the current set of reviewers whose judgement I/we can trust. By that standard nothing will ever change. Ever. Even twenty years from now, you will still only trust people that are familiar with shell, Perl, and C. Because the only way to gain your trust, is by being proficient in shell, Perl, and C. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: Hi Greg, On Thu, 6 Jun 2013, Greg Troxel wrote: As one of the people who helps maintain git packages in pkgsrc, my initial reaction is negative to adding a ruby dependency. My initial reaction, too. It was hard enough to get Perl included with Git for Windows (because of that pesky Subversion dependency). As you can see from the commit history, I was the primary force behind trying to get everything core in Git away from requiring scripting languages (I think it is an awesome thing to provide APIs for as many languages as possible, but a not-so-cool thing to use more than one language in the core code). It does not seem that anybody picked up that task when I left, though. Nobody seems to mention it yet. There's another reason behind the C rewrite effort: fork is costly on Windows. The C rewrite allows us to run with one process (most of the time). This applies for shell, perl and even ruby scripts because libgit.a is never meant to be used outside git.c context (unlike libgit2). In this regard, ruby is just as bad as currently supported non-C languages. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras felipe.contre...@gmail.com wrote: The reviewer pool for code written in a new language _must_ be seeded by some from the current set of reviewers whose judgement I/we can trust. By that standard nothing will ever change. Ever. Even twenty years from now, you will still only trust people that are familiar with shell, Perl, and C. Because the only way to gain your trust, is by being proficient in shell, Perl, and C. I don't see why a trusted person cannot learn a new language and convince the community to give it a try (well given that enough reviewers support the new language, which was Junio's point). -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On 5 June 2013 16:45, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano gits...@pobox.com wrote: That might make sense for the shorter term, but in longer term I see Perl as declining in favor of other languages. It's only a matter of time before Ruby surpasses Perl in popularity, and soon enough new contributors to the Git project will have problems trying to improve Git because parts of it are written in a language they are not familiar with, and have trouble learning (isn't that already happening?). The Ruby vs. Python is another question altogether, I could go into detail about why I think Ruby is a better choice, but my point right now is that Perl is not a good choice for the future. Good thing you are being objective and leaving out the Python 3.0 mess, the long legacy of backwards compatibility in the Perl community, the active community behind it, its extensive portability support, and fail to mention the lack of an equivalent to CPAN. We wouldn't want facts to get in the way of a personal bias would we? Just thought I'd push back on the FUD. People have been saying Perl is going away for decades... Yves -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 2:26 AM, demerphq demer...@gmail.com wrote: On 5 June 2013 16:45, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano gits...@pobox.com wrote: That might make sense for the shorter term, but in longer term I see Perl as declining in favor of other languages. It's only a matter of time before Ruby surpasses Perl in popularity, and soon enough new contributors to the Git project will have problems trying to improve Git because parts of it are written in a language they are not familiar with, and have trouble learning (isn't that already happening?). The Ruby vs. Python is another question altogether, I could go into detail about why I think Ruby is a better choice, but my point right now is that Perl is not a good choice for the future. Good thing you are being objective and leaving out the Python 3.0 mess, the long legacy of backwards compatibility in the Perl community, the active community behind it, its extensive portability support, and fail to mention the lack of an equivalent to CPAN. We wouldn't want facts to get in the way of a personal bias would we? None of that has anything to do with Perl's popularity. Just thought I'd push back on the FUD. People have been saying Perl is going away for decades... Perl has been going away for the last decade [1], and will continue to go away. Perl is going away, and that an undeniable fact, and if you are not interested in discussing on the basis of reality, I'm not interested in discussing with you. [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote: On Thu, Jun 6, 2013 at 2:26 AM, demerphq demer...@gmail.com wrote: Good thing you are being objective and leaving out the Python 3.0 mess, the long legacy of backwards compatibility in the Perl community, the active community behind it, its extensive portability support, and fail to mention the lack of an equivalent to CPAN. We wouldn't want facts to get in the way of a personal bias would we? None of that has anything to do with Perl's popularity. Just thought I'd push back on the FUD. People have been saying Perl is going away for decades... Perl has been going away for the last decade [1], and will continue to go away. Perl is going away, and that an undeniable fact, and if you are not interested in discussing on the basis of reality, I'm not interested in discussing with you. [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png I don't think the usefulness of a language should be judged by hits on a web site. Personally I would like the Git client to be packaged with as few dependencies as possible. Right now that seems to require Shell, Sed, Awk and Perl. The documentation has other requirements, but a prebuild tar file is available. I would have the rest of the distribution be bundled as something like git-utils which could have a subdirectory for each support language. Then one could even make available alternative implementations of higher level utilities and people could decide if support of a specific language was useful to them. Most such extension code is simple, although more complex than suitable for just Shell/Sed/Awk. People in each language community could provide code which meets the needs of their community, and the Git project itself would not need to make (Solomon like) decisions about what extension languages to support. -- Barry Fishman -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Michael Haggerty mhag...@alum.mit.edu writes: * at the source-code level, a tool in contrib can take advantage of some of the Git build/test infrastructure, though I don't know whether they currently do. They do not do much AFAICT. For example, contrib/subtree/t/Makefile is essentially copy-pasted from Git's equivalent. But they can do to some extend, for example make install in contrib/mw-to-git/ re-uses Git's Makefile to hardcode the PERL_PATH in the file, find Git's exec-path so. I'd love to be able to use Documentation/Makefile and t/Makefile too for external programs meant to be used as a Git command. That does not strictly imply that these commands be maintained within git.git, as we could imagine: * Ask the user to build external programs with make GIT_ROOT=where/git/lives/ * or, ask users to checkout the external program as a subdirectory of git.git to build it (for example, clang's build installation ask you to put clang as a subdirectory of LLVM's tree). But my main point is that I think it would be easier to phase out contrib/ if there were a good alternate way of providing visibility to satellite projects. [...] Perhaps ranking the tools based on the results of the Git user surveys would help bring the most popular to the top of each category. I think this is the most important point. A good example would be git-multimail: for now, the shell version in contrib/ is somehow considered as the official hook to send emails, just because it is in contrib, while git-multimail is clearly superior (unless you don't have a python interpreter on your server). I also see contrib/ as a safe place to live, in that the likeliness for the project to be abandonned is rather small. Especially for small pieces of code, it's easy to create a repo and throw the code somewhere on GitHub, but maintaining it is harder. Take again the example of post-receive-email, the code was originally written by Andy Parkins, but the community took over it (Andy's last commit on the script was in 2008). I'm not sure this would have been so easy with a script hosted on an arbitrary repo. I'm not opposed to Junio's proposal to restrict contrib/ (although a bit reluctant), but I think this should be done with care, at least to give potential users a way to chose which tool to use (really, nobody want to go use https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools to pick the right tool. It's a great list, but not a guide). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 7:24 AM, Barry Fishman barry_fish...@acm.org wrote: On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote: On Thu, Jun 6, 2013 at 2:26 AM, demerphq demer...@gmail.com wrote: Good thing you are being objective and leaving out the Python 3.0 mess, the long legacy of backwards compatibility in the Perl community, the active community behind it, its extensive portability support, and fail to mention the lack of an equivalent to CPAN. We wouldn't want facts to get in the way of a personal bias would we? None of that has anything to do with Perl's popularity. Just thought I'd push back on the FUD. People have been saying Perl is going away for decades... Perl has been going away for the last decade [1], and will continue to go away. Perl is going away, and that an undeniable fact, and if you are not interested in discussing on the basis of reality, I'm not interested in discussing with you. [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png I don't think the usefulness of a language should be judged by hits on a web site. Nobody is judging the usefulness of a language, I have plenty of arguments for that, but this is about popularity. Personally I would like the Git client to be packaged with as few dependencies as possible. Right now that seems to require Shell, Sed, Awk and Perl. The documentation has other requirements, but a prebuild tar file is available. I would be perfectly fine with replacing shell, sed, awk and perl with ruby. But that's not what you are arguing, is it? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On 2013-06-06 09:01:48 EDT, Felipe Contreras wrote: On Thu, Jun 6, 2013 at 7:24 AM, Barry Fishman barry_fish...@acm.org wrote: On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote: On Thu, Jun 6, 2013 at 2:26 AM, demerphq demer...@gmail.com wrote: Good thing you are being objective and leaving out the Python 3.0 mess, the long legacy of backwards compatibility in the Perl community, the active community behind it, its extensive portability support, and fail to mention the lack of an equivalent to CPAN. We wouldn't want facts to get in the way of a personal bias would we? None of that has anything to do with Perl's popularity. Just thought I'd push back on the FUD. People have been saying Perl is going away for decades... Perl has been going away for the last decade [1], and will continue to go away. Perl is going away, and that an undeniable fact, and if you are not interested in discussing on the basis of reality, I'm not interested in discussing with you. [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png I don't think the usefulness of a language should be judged by hits on a web site. Nobody is judging the usefulness of a language, I have plenty of arguments for that, but this is about popularity. I used usefulness in its general vague sense. It is useful to be popular, I don't make choices solely on that or I would be writing everything in Java. Personally I would like the Git client to be packaged with as few dependencies as possible. Right now that seems to require Shell, Sed, Awk and Perl. The documentation has other requirements, but a prebuild tar file is available. I would be perfectly fine with replacing shell, sed, awk and perl with ruby. But that's not what you are arguing, is it? I'm talking about porcelain code and not core functionality which should be left in C. I'm saying that you should be free to provide Ruby implementations of all such superstructure. And the same can be done by (but not required by) the Perl, Python, Tcl and even C, Haskel, Guile and whatever communities. Most such higher level code is fairly trivial, and if the file names are kept the same, the same test procedures could be run. I don't think the cost of duplication of code functionality is that significant, since it would bring new people to the project. After all this is a free project and not a commerical venture. It certainly helps porting to new platforms. Separate language communities would be maintaining their own contributions, with their own experimental directories. Translating the same functionality to multiple languages requires careful reading which can help identify some hidden bugs. -- Barry Fishman -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 8:46 AM, Barry Fishman barry_fish...@acm.org wrote: On 2013-06-06 09:01:48 EDT, Felipe Contreras wrote: Nobody is judging the usefulness of a language, I have plenty of arguments for that, but this is about popularity. I used usefulness in its general vague sense. It is useful to be popular, I don't make choices solely on that or I would be writing everything in Java. Straw man. Personally I would like the Git client to be packaged with as few dependencies as possible. Right now that seems to require Shell, Sed, Awk and Perl. The documentation has other requirements, but a prebuild tar file is available. I would be perfectly fine with replacing shell, sed, awk and perl with ruby. But that's not what you are arguing, is it? I don't know what you are saying, but it clearly has nothing to do with the point. Perl is declining, and it would be wise to use another language instead of it. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On 2013-06-06 10:09:21 EDT, Felipe Contreras wrote: I don't know what you are saying, but it clearly has nothing to do with the point. Perl is declining, and it would be wise to use another language instead of it. You want a simple statement. I don't particulary like Perl, but it has worked well for the project. If you have a better solution, then write all the code to replace it, and demonstrate with a significant number of active users that your solution works out better in practice. Wasn't that how Git started? -- Barry Fishman -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 9:41 AM, Barry Fishman barry_fish...@acm.org wrote: On 2013-06-06 10:09:21 EDT, Felipe Contreras wrote: I don't know what you are saying, but it clearly has nothing to do with the point. Perl is declining, and it would be wise to use another language instead of it. You want a simple statement. I don't particulary like Perl, but it has worked well for the project. It would serve it less and less as the years go by. If you have a better solution, then write all the code to replace it, False dichotomy fallacy. I don't need to do that. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, 6 Jun 2013, Felipe Contreras wrote: In the end my point remains unchanged; Perl is declining, so it would be wise for the future to use another scripting language instead. Perl use may or may not be declining (depending on how you measure it), but are you really willing to take on the task of re-writing everything that's in Perl into another language and force all developers of scripts to learn that other language? what's the ROI of this? Perl isn't going to disappear any time soon. What makes you think that whatever language you pick to replace Perl is going to be more stable than Perl is? and, like the parent poster, by 'stable' I mean from the compatibility point of view. What are the odds that the 'newer' language that you pick is going to pull a python 3 on you? There have been a very large number of scripting languages show up, make a lot of press, and then fade in favor of other languages while Perl has continued. It's not the sexy languange nowdays, but it's there, reliable, and used so heavily that there's really no chance of it dissapearing in the forseable future. David Lang -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Felipe Contreras felipe.contre...@gmail.com writes: On Thu, Jun 6, 2013 at 9:54 AM, Greg Troxel g...@ir.bbn.com wrote: git is a core tool that people use on almost the smallest of boxes, perhaps even replacing rcs for managing local config files. On such machines, even perl may be large, but a second scripting language seems excessive. You can compile Git without any of them. That ignores the 99% of people who use packaged versions. The question is really Should the standared approach for building be to use or not use dependency X?. Really this should be expressed in the README, and it creates expectations for someone who just installs the git package in terms of whether pieces of functionality are there. Packagers generally should be reading the README and including required/recommended dependencies and not including optional dependencies (in the main package). The information in INSTALL is pretty reasonable, but it doesn't really clearly say if you hand someone git built without perl, it is { perfectly ok but missing a fringe optional feature | deficient because git add -p won't work }. I'm leaning towards the deficient camp. So you can compile git without X should really translate into when one runs the default build following the instructions, and does not take affirmative steps to use X, X should not be used or depended on. If it doesn't mean that, it doesn't help the packaging/expectations discussion. It's of course fine that one can hand-compile a smaller than standard but still useful subset. But that's entirely different from the definition of normal. On a NetBSD 6 i386 system, the size of the ruby193-base binary package (as installed) is 25 MB (vs 15 MB for the git base package, which lacks gitk and docs). (Presently, the git base package defaults to requiring python and installing the git_remote_helpers, but I think that's a bug.) perl is 54 MB. That's only the default, if the default doesn't suit you, don't use the default. It's not about what I want. It's about making choices that affect other people, and trying to find a plan that will be overall reasonable; that's the essence of stewardship in packaging. Compiling for just myself is far easier. pgpEWOFl1E9Ut.pgp Description: PGP signature
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 11:09 AM, David Lang da...@lang.hm wrote: On Thu, 6 Jun 2013, Felipe Contreras wrote: In the end my point remains unchanged; Perl is declining, so it would be wise for the future to use another scripting language instead. Perl use may or may not be declining (depending on how you measure it), but are you really willing to take on the task of re-writing everything that's in Perl into another language and force all developers of scripts to learn that other language? But that's exactly what we are asking the newer generations of developers; to learn another language. Fewer and fewer new contributors will come with knowledge of Perl. What are the odds that the 'newer' language that you pick is going to pull a python 3 on you? Ruby 2 speaks volumes on that front. There have been a very large number of scripting languages show up, make a lot of press, and then fade in favor of other languages while Perl has continued. It's not the sexy languange nowdays, but it's there, reliable, and used so heavily that there's really no chance of it dissapearing in the forseable future. Yet it's declining, more and more every year. And the more the time goes by, the more we hurt ourselves. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 12:16 PM, Greg Troxel g...@ir.bbn.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Thu, Jun 6, 2013 at 9:54 AM, Greg Troxel g...@ir.bbn.com wrote: git is a core tool that people use on almost the smallest of boxes, perhaps even replacing rcs for managing local config files. On such machines, even perl may be large, but a second scripting language seems excessive. You can compile Git without any of them. That ignores the 99% of people who use packaged versions. The 99% of people who use packaged versions wouldn't care about the additional dependency. On a NetBSD 6 i386 system, the size of the ruby193-base binary package (as installed) is 25 MB (vs 15 MB for the git base package, which lacks gitk and docs). (Presently, the git base package defaults to requiring python and installing the git_remote_helpers, but I think that's a bug.) perl is 54 MB. That's only the default, if the default doesn't suit you, don't use the default. It's not about what I want. It is exactly about what you want. You use the argument that 99% of the people use packaged versions, yet you ignore the fact that 99% of the people don't care about a single extra dependency (specially one that would be transitory). It is all about 1% of the users, in fact, not even that, because of this 1% of users who dread extra dependencies, most of them would be happy that it's only temporary, and eventually a heavier dependency would be replaced with a lighter one. It is for all intents and purposes only you, the person you are speaking on behalf of. If the Git project considers a new dependency that would be needed in addition to Perl for a finite period of time, your argument does absolutely nothing to block this route. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Wed, Jun 5, 2013 at 6:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote: But my main point is that I think it would be easier to phase out contrib/ if there were a good alternate way of providing visibility to satellite projects. The relevant Git wiki page [1] is the most likely candidate, but it is a bit overwhelming due to its size, it has fallen into disuse because it was broken for such a long time, and it is not prominently linked to from git-scm.com. If it were curated a bit, it would help users find the best ancillary tools quickly. Perhaps ranking the tools based on the results of the Git user surveys would help bring the most popular to the top of each category. One idea here could be to mirror what the libgit2 project [1] (and many others) are doing on GitHub. Use the organization unit [2] as an umbrella for the contrib projects. If necessary, put a pretty web-page on top [3]. Of course you don't have to tie it to GitHub, but they do have some nice mechanisms for showing off popularity (stars and forks). I heard that clojure/contrib [4] went through a big clean-up recently, although I'm not sure if there was an equivalent reasoning behind it. But their guide-lines on what should go into contrib may have some good ideas [5]. [1] https://github.com/libgit2 [2] https://github.com/git [3] http://libgit2.github.com/ [4] http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go [5] http://dev.clojure.org/pages/viewpage.action?pageId=5767464 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
David Lang wrote: Perl use may or may not be declining (depending on how you measure it), but are you really willing to take on the task of re-writing everything that's in Perl into another language and force all developers of scripts to learn that other language? what's the ROI of this? Let's not talk hypotheticals. git-svn.perl (+ perl/SVN/*.pl) is absolutely massive. It's an incredibly useful tool in that it actually works, and that there is nothing replacing it in the foreseeable future. This monster was written almost entirely by one brilliant person, and nobody is going to rewrite it. We don't start a huge discussion about what languages are approved before accepting such a contribution: if the contributor wants to write something in a dominant language (Perl in this case), and it's going to be useful, we merge it. End of story. All this planning is a colossal waste of time, in my opinion. Perl isn't going to disappear any time soon. What makes you think that whatever language you pick to replace Perl is going to be more stable than Perl is? Why are we discussing something that is indeterminate? It is impossible to foresee the future, but that is no reason to freeze _present_ development. and, like the parent poster, by 'stable' I mean from the compatibility point of view. Various programming languages have different philosophies, and have grown in different ways. What matters is that some of them have a large number of users, and we're talking about one such example. What are the odds that the 'newer' language that you pick is going to pull a python 3 on you? This has to be a rhetorical, because I don't imagine you expect anyone to predict the future. As Felipe already pointed out Ruby 2.0 is a good sign. There have been a very large number of scripting languages show up, make a lot of press, and then fade in favor of other languages while Perl has continued. It's not the sexy languange nowdays, but it's there, reliable, and used so heavily that there's really no chance of it dissapearing in the forseable future. Nobody claimed that press coverage is a good metric. We can only talk about facts, and Felipe already showed you a TIOBE index graph. If you have overwhelming _evidence_ that Ruby is a weak language that will die soon, share it: otherwise, I see no value in this discussion. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Johannes Schindelin wrote: My initial reaction, too. It was hard enough to get Perl included with Git for Windows (because of that pesky Subversion dependency). Nevertheless, we had to do it, and we did it. We will do it again, if we get enough important code written in Ruby. As you can see from the commit history, I was the primary force behind trying to get everything core in Git away from requiring scripting languages (I think it is an awesome thing to provide APIs for as many languages as possible, but a not-so-cool thing to use more than one language in the core code). It does not seem that anybody picked up that task when I left, though. Rewriting everything in C? Is anyone bored enough to pick up this task? Bourne shell is a great language for prototyping; git-rebase.sh (and friends), git-stash.sh, git-pull.sh are doing just fine. Sure, it makes sense to do heavy-lifting in C, and this is happening as it has always been happening (remember git-commit.sh?). If you followed the list emails, you'd know that Felipe is looking into delegating large portions of the work done by git-rebase.sh to sequencer.c. Anyway, all this talk about some hypothetical ideas just bores me. What matters is what is currently happening. And nobody is actively rewriting the core in Git in C, so I don't see the point of discussing anything but patches. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On 06/06/2013 01:46 AM, Felipe Contreras wrote: On Thu, Jun 6, 2013 at 2:26 AM, demerphq demer...@gmail.com wrote: Good thing you are being objective and leaving out the Python 3.0 mess, the long legacy of backwards compatibility in the Perl community, the active community behind it, its extensive portability support, and fail to mention the lack of an equivalent to CPAN. We wouldn't want facts to get in the way of a personal bias would we? None of that has anything to do with Perl's popularity. Just thought I'd push back on the FUD. People have been saying Perl is going away for decades... Perl has been going away for the last decade [1], and will continue to go away. Perl is going away, and that an undeniable fact, and if you are not interested in discussing on the basis of reality, I'm not interested in discussing with you. [1] http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png The linchpin of your argument is that Perl is dying. Let's assume that the TIOBE index is a reliable basis for making business decisions--it's not, but let's pretend--the graph you linked to doesn't even seem to support your conclusion (or am I missing something?). It looks like Perl's popularity has pretty much been constant for at least two years. It's apparently not increasing in popularity, but this isn't an electrocardiogram (i.e. flat-lining is not dead or even dying). The same graph shows that Ruby's popularity also hasn't changed very much since 2007 after its initial surge. Now, it's probably too off-topic to pick apart TIOBE's methodology here, but suffice it to say that, like any trend indicator, it's only as useful as your knowledge of its limitations, and this has been discussed enough elsewhere. It's true that Perl isn't soon going to win any trendiness awards, but the same reasons that made Perl a good choice for git so many years ago are still there and then some. You would probably also be surprised at the number of new kids learning Perl. I guess I just denied the undeniable fact that Perl is going away, so maybe I'm one of those with whom you do not want to discuss this, but, for my part, I am willing to consider other evidence for the claim. As I pointed out, the evidence shown so far (one reference to the TIOBE index) isn't nearly enough to settle the matter. I also apologize for dragging this out if this thread is judged to not be worth a whole lot. -- Charles McGarvey signature.asc Description: OpenPGP digital signature
Re: [Administrivia] On ruby and contrib/
Greg Troxel wrote: It's not about what I want. It's about making choices that affect other people, and trying to find a plan that will be overall reasonable; that's the essence of stewardship in packaging. Compiling for just myself is far easier. Have you asked the SBCL or Google-Chrome package maintainers what they have to deal with? I believe they're packaging nightmares. GHC/ Haskell projects aren't far behind. Git is probably the _last_ thing to be complaining about when it comes to packaging. Sure, people want to run Git on embedded devices like Rpi. The core is already in C and Bourne Shell, and I don't see anyone rewriting that in Ruby. No cause for concern. That ignores the 99% of people who use packaged versions. The question is really Should the standared approach for building be to use or not use dependency X?. Really this should be expressed in the README, and it creates expectations for someone who just installs the git package in terms of whether pieces of functionality are there. Packagers generally should be reading the README and including required/recommended dependencies and not including optional dependencies (in the main package). The information in INSTALL is pretty reasonable, but it doesn't really clearly say if you hand someone git built without perl, it is { perfectly ok but missing a fringe optional feature | deficient because git add -p won't work }. I'm leaning towards the deficient camp. So whom is this extra dependency affecting, if 99% of users are using packaged versions? So, it's just extra burden for the package maintainers (and users on source-based distributions)? git-svn and git-send-email are already separate packages on Ubuntu/Debian because they depend on lots of CPAN packages that can be non-trivial to install for new users. If we do get one important Ruby script, ship it as a separate package: done? At the moment, there's just contrib/git-related that depends on ruby. Can we just stop planning centuries in advance, and tackle the problem when it arises? It remains to be determined whether or not git.git will grow a healthy ruby sub-ecosystem. If it does, package maintainers will be inconvenienced slightly. Otherwise, we'll just throw out the ruby code that's rotting in our tree, and get on with our lives. The direction of the project is not decided on the basis of some vague future packaging expectations. It's decided on the basis of what patches come in from contributors, and everything else is secondary. If people want to write ruby, they will write ruby. Whether or not the git project welcomes their contributions. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote: David Lang wrote: Perl use may or may not be declining (depending on how you measure it), but are you really willing to take on the task of re-writing everything that's in Perl into another language and force all developers of scripts to learn that other language? what's the ROI of this? Let's not talk hypotheticals. git-svn.perl (+ perl/SVN/*.pl) is absolutely massive. It's an incredibly useful tool in that it actually works, and that there is nothing replacing it in the foreseeable future. This monster was written almost entirely by one brilliant person, and nobody is going to rewrite it. We don't start a huge discussion about what languages are approved before accepting such a contribution: if the contributor wants to write something in a dominant language (Perl in this case), and it's going to be useful, we merge it. End of story. Well, Felipe is saying that Perl is dieing and we should re-write everything that exists in Perl to Ruby. Part of the reason for the discussion now is because not having similar discussions in the past have caused problems. All this planning is a colossal waste of time, in my opinion. Perl isn't going to disappear any time soon. What makes you think that whatever language you pick to replace Perl is going to be more stable than Perl is? Why are we discussing something that is indeterminate? It is impossible to foresee the future, but that is no reason to freeze _present_ development. and it's not a reason to throw away existing stuff based on the argument that Perl is dieing There have been a very large number of scripting languages show up, make a lot of press, and then fade in favor of other languages while Perl has continued. It's not the sexy languange nowdays, but it's there, reliable, and used so heavily that there's really no chance of it dissapearing in the forseable future. Nobody claimed that press coverage is a good metric. We can only talk about facts, and Felipe already showed you a TIOBE index graph. If you have overwhelming _evidence_ that Ruby is a weak language that will die soon, share it: otherwise, I see no value in this discussion. TIOBE index graph is press coverage as far as I'm concerned. I'm not saying that Ruby in particular has a fatal flaw, I'm just questioning the Perl is dead, re-write everything in Ruby mantra. The language that you choose to use when writing a new application is related to things related to that type of application. Ruby is not an extremely common language for sysadmins to use. Perl remains a common language for these sorts of tasks, even if it's not used for user visible applications. Arguing that Perl is dieing, we need to abandon it is just wrong. David Lang -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dependencies and packaging (Re: [Administrivia] On ruby and contrib/)
Ramkumar Ramachandra wrote: Git is probably the _last_ thing to be complaining about when it comes to packaging. It would be nice if contrib/ files supported the usual make; make install; make clean targets. That's missing functionality that does matter to at least one packager. It would be nice if the dependencies associated to each piece of functionality or makefile flag were documented more clearly. Currently when e.g. features of gitweb gain dependencies I don't notice until the testsuite fails. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Hi Ram, On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote: Johannes Schindelin wrote: My initial reaction, too. It was hard enough to get Perl included with Git for Windows (because of that pesky Subversion dependency). Nevertheless, we had to do it, and we did it. That is not quite correct. *I* did it. Not *we*. And I will not do it again. We will do it again, if we get enough important code written in Ruby. I am a bit bored by this hypothetical talk. This hypothetical we will do it again, to be precise. Given my experience, it would be very painful if enough important code was written in Ruby. Nobody would help me do it again. Just like nobody helps right now to upgrade to a newer Perl. Feel free to prove me wrong. Until that time, I will firmly believe that there is no we will do it again. So here is a chance to prevent that: not repeat the mistake, and stay away from language hell by avoiding to require yet another language. As you can see from the commit history, I was the primary force behind trying to get everything core in Git away from requiring scripting languages (I think it is an awesome thing to provide APIs for as many languages as possible, but a not-so-cool thing to use more than one language in the core code). It does not seem that anybody picked up that task when I left, though. Rewriting everything in C? Is anyone bored enough to pick up this task? Bourne shell is a great language for prototyping; git-rebase.sh (and friends), git-stash.sh, git-pull.sh are doing just fine. Sure, it makes sense to do heavy-lifting in C, and this is happening as it has always been happening (remember git-commit.sh?). If you followed the list emails, you'd know that Felipe is looking into delegating large portions of the work done by git-rebase.sh to sequencer.c. As you know, there are very good reasons why I do not follow those mails. Anyway, all this talk about some hypothetical ideas just bores me. What matters is what is currently happening. And nobody is actively rewriting the core in Git in C, so I don't see the point of discussing anything but patches. Exactly. Nobody really cares about keeping Git portable enough. Hence my impression that this idea to start requiring yet another language for core parts of Git is a bit misguided, and only logical from the point of view: If you don't like it, why don't you install Linux? (which, just in case you wondered, is a pretty naive way of looking at the real world). Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Tue, Jun 4, 2013 at 10:02 PM, David Lang da...@lang.hm wrote: On Tue, 4 Jun 2013, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: On Ruby: Assuming related is a good idea, to make it as the proper part of the system out of contrib/ when its design review phase is finished, one of these things has to happen: 1. Find a volunteer to rewrite it in one of the languages that we know the platforms our current users use already support, which means either C (not a good match), POSIX shell (not the best match), or Perl. 2. Promote Ruby to the first-class citizen status, which involves making sure people on platforms that matter do not have problem adding dependency on it (I am primarily worried about MinGW folks), and also making sure core developers do not mind reviewing code written in it. As long as we can get as high quality reviews on changes written in Ruby as we do for the current codebase, it is OK to go route #2, and that may hopefully happen in the longer term as and there will be some people, among competent Ruby programmers, who have understood how the pieces of entire Git are designed to fit together by the time it happens. I however do not know how much extra burden it would place to add dependencies to platform folks, so obviously the safer approach is 1 at least in the immediate future. My understanding is that msysgit folks are already having trouble with Python, and we do not want to go route #2 at least for now. Having to ship a variant of Git with NO_PYTHON is already bad enough. And that is why the option 1 above does not list Python as a possible candidate. As someone who builds minimalist builds (firewalls, openwrt, raspberry pi, etc), having to pull in a full ruby install to get git installed would not be something I'd like to see. You wouldn't _have_ to, just like you don't _have_ to install Python right now. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: I however do not know how much extra burden it would place to add dependencies to platform folks, so obviously the safer approach is 1 at least in the immediate future. My understanding is that msysgit folks are already having trouble with Python, and we do not want to go route #2 at least for now. Having to ship a variant of Git with NO_PYTHON is already bad enough. And that is why the option 1 above does not list Python as a possible candidate. This rests on the assumption that Ruby would be as difficult to distribute as Python, which might not be the case. As the maintainer, I've been thinking about closing contrib/ area for new stuff, and shrinking existing ones, either by moving stuff that are only useful within the context of Git to main part of the tree (e.g. contrib/workdir may move to a new directory addons/, some of remote-helpers in contrib/ may move to remote-helpers/, etc.), and removing others from contrib/, for this reason. Of course, interested folks can take the last version of the removed ones and continue improving them as standalone projects. This does make sense, however, I do think some parts of Git might be more maintainable if they have their own Makefile (e.g. bash completion), where it's clear where they should be installed by default. Either way, the user might want to do 'install-all' or 'install-addons', to install all these things, and I think a good rule of thumb is that if we don't want 'install-all' to install certain script (eventually), then that script probably doesn't belong in 'contrib' (or anywhere in Git). The rest is just a personal opinion. If we were looking at a compelling and sizeable web application that depends on Rails, it is very likely that it would not make much sense to rewrite it in other languages only to avoid a new language dependency on Ruby. But related is read and extract some info out of text files, spawn a 'blame' (or two) based on that info, read to collect further info and summarize, for which Ruby does not especially shine compared to Perl, which is the language we already depend on. Because of this, I am moderately reluctant to add Ruby dependency only for this script. Unless I know people who regularly give us high quality reviews, and those who support various platforms, are fine with it, that is. In the shorter term (read: up to 2.0), I am inclined to vote that we should go route #1 (i.e. rewrite in Perl once the design settles). That might make sense for the shorter term, but in longer term I see Perl as declining in favor of other languages. It's only a matter of time before Ruby surpasses Perl in popularity, and soon enough new contributors to the Git project will have problems trying to improve Git because parts of it are written in a language they are not familiar with, and have trouble learning (isn't that already happening?). The Ruby vs. Python is another question altogether, I could go into detail about why I think Ruby is a better choice, but my point right now is that Perl is not a good choice for the future. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Administrivia] On ruby and contrib/
Junio C Hamano gits...@pobox.com writes: * fc/contrib-related (2013-06-03) 4 commits - contrib: related: parse committish like format-patch - contrib: related: add option to parse from committish - contrib: related: add support for multiple patches - Add new git-related helper to contrib Waiting for the design review to settle. As people may have seen in the discussion on the earlier iteration, something like this (there may be a room for bikeshedding the name, though) that takes either a range of changes or set of patches and finds people who may be able to review them may be a good addition to our official toolchest. http://thread.gmane.org/gmane.comp.version-control.git/221728/focus=221796 Right now, related is in contrib/ primarily because its design review phase is not yet finished and because it is in Ruby, which the rest of the system does not depend on. I have some administrative comments on two issues as the maintainer. * Do we want to add Ruby dependency? * Do we want to keep expanding contrib/? These have been triggered by related, but the comments in this message are not limited to the specific topic (e.g. you can read it with s/Ruby/any language we currently do not depend on/). On Ruby: Assuming related is a good idea, to make it as the proper part of the system out of contrib/ when its design review phase is finished, one of these things has to happen: 1. Find a volunteer to rewrite it in one of the languages that we know the platforms our current users use already support, which means either C (not a good match), POSIX shell (not the best match), or Perl. 2. Promote Ruby to the first-class citizen status, which involves making sure people on platforms that matter do not have problem adding dependency on it (I am primarily worried about MinGW folks), and also making sure core developers do not mind reviewing code written in it. As long as we can get as high quality reviews on changes written in Ruby as we do for the current codebase, it is OK to go route #2, and that may hopefully happen in the longer term as and there will be some people, among competent Ruby programmers, who have understood how the pieces of entire Git are designed to fit together by the time it happens. I however do not know how much extra burden it would place to add dependencies to platform folks, so obviously the safer approach is 1 at least in the immediate future. My understanding is that msysgit folks are already having trouble with Python, and we do not want to go route #2 at least for now. Having to ship a variant of Git with NO_PYTHON is already bad enough. And that is why the option 1 above does not list Python as a possible candidate. On contrib/: Back when Git was very young, it made sense to bundle third-party tools in our tree's contrib/ section to give them visibility and users convenience. Now Git ecosystem has grown to have many users who know Git and who do not necessarily come to this list, and with easy-to-use hosting sites where anybody can publish their ware and collaborate with their contributors, giving more visibility angle of contrib/ has outlived its usefulness. When there are multiple third-party tools that address similar needs, there is not much point picking one at random and ship it over others, and shipping all of them is simply crazy. In an ecosystem with flourishing third-party add-ons, their products should and will stand on their own. As the maintainer, I've been thinking about closing contrib/ area for new stuff, and shrinking existing ones, either by moving stuff that are only useful within the context of Git to main part of the tree (e.g. contrib/workdir may move to a new directory addons/, some of remote-helpers in contrib/ may move to remote-helpers/, etc.), and removing others from contrib/, for this reason. Of course, interested folks can take the last version of the removed ones and continue improving them as standalone projects. And that is why the list of possible actions in the previous part does not have 3. Keep it in contrib/ forever as an option. That is all for the administrative comments as the maintainer. The rest is just a personal opinion. If we were looking at a compelling and sizeable web application that depends on Rails, it is very likely that it would not make much sense to rewrite it in other languages only to avoid a new language dependency on Ruby. But related is read and extract some info out of text files, spawn a 'blame' (or two) based on that info, read to collect further info and summarize, for which Ruby does not especially shine compared to Perl, which is the language we already depend on. Because of this, I am moderately reluctant to add Ruby dependency only for this script. Unless I know people who regularly give us high quality reviews, and those who support various platforms, are fine with it, that is. In the shorter term (read: up to 2.0), I am inclined to vote that we
Re: [Administrivia] On ruby and contrib/
On Tue, 4 Jun 2013, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: On Ruby: Assuming related is a good idea, to make it as the proper part of the system out of contrib/ when its design review phase is finished, one of these things has to happen: 1. Find a volunteer to rewrite it in one of the languages that we know the platforms our current users use already support, which means either C (not a good match), POSIX shell (not the best match), or Perl. 2. Promote Ruby to the first-class citizen status, which involves making sure people on platforms that matter do not have problem adding dependency on it (I am primarily worried about MinGW folks), and also making sure core developers do not mind reviewing code written in it. As long as we can get as high quality reviews on changes written in Ruby as we do for the current codebase, it is OK to go route #2, and that may hopefully happen in the longer term as and there will be some people, among competent Ruby programmers, who have understood how the pieces of entire Git are designed to fit together by the time it happens. I however do not know how much extra burden it would place to add dependencies to platform folks, so obviously the safer approach is 1 at least in the immediate future. My understanding is that msysgit folks are already having trouble with Python, and we do not want to go route #2 at least for now. Having to ship a variant of Git with NO_PYTHON is already bad enough. And that is why the option 1 above does not list Python as a possible candidate. As someone who builds minimalist builds (firewalls, openwrt, raspberry pi, etc), having to pull in a full ruby install to get git installed would not be something I'd like to see. Yes, openwrt (and I) can build our own version, but that's a pain. I tend to build my tight systems from Debian and it's nice to be able to use stock packages. I tend to use git for sysadmin type functions as much as for development, so it's very useful even on such small and slow platforms. On contrib/: Back when Git was very young, it made sense to bundle third-party tools in our tree's contrib/ section to give them visibility and users convenience. Now Git ecosystem has grown to have many users who know Git and who do not necessarily come to this list, and with easy-to-use hosting sites where anybody can publish their ware and collaborate with their contributors, giving more visibility angle of contrib/ has outlived its usefulness. When there are multiple third-party tools that address similar needs, there is not much point picking one at random and ship it over others, and shipping all of them is simply crazy. In an ecosystem with flourishing third-party add-ons, their products should and will stand on their own. As the maintainer, I've been thinking about closing contrib/ area for new stuff, and shrinking existing ones, either by moving stuff that are only useful within the context of Git to main part of the tree (e.g. contrib/workdir may move to a new directory addons/, some of remote-helpers in contrib/ may move to remote-helpers/, etc.), and removing others from contrib/, for this reason. Of course, interested folks can take the last version of the removed ones and continue improving them as standalone projects. If you can, you should leave just enough of a stub in place so that people who don't know about the change and try to run the stuff that used to be in contrib/ get a message pointing them to the new home. David Lang -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On 06/05/2013 02:04 AM, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: * fc/contrib-related (2013-06-03) 4 commits - contrib: related: parse committish like format-patch - contrib: related: add option to parse from committish - contrib: related: add support for multiple patches - Add new git-related helper to contrib Waiting for the design review to settle. As people may have seen in the discussion on the earlier iteration, something like this (there may be a room for bikeshedding the name, though) that takes either a range of changes or set of patches and finds people who may be able to review them may be a good addition to our official toolchest. http://thread.gmane.org/gmane.comp.version-control.git/221728/focus=221796 Right now, related is in contrib/ primarily because its design review phase is not yet finished and because it is in Ruby, which the rest of the system does not depend on. I have some administrative comments on two issues as the maintainer. * Do we want to add Ruby dependency? * Do we want to keep expanding contrib/? These have been triggered by related, but the comments in this message are not limited to the specific topic (e.g. you can read it with s/Ruby/any language we currently do not depend on/). On Ruby: [...] I don't have an opinion on allowing Ruby into the core, except to say that I would personally prefer *some* alternative that is more capable than shell and more modern and self-consistent than Perl. Python, Ruby, and Lua would seem to be the obvious candidates, with the latter being easiest for packagers. On contrib/: Back when Git was very young, it made sense to bundle third-party tools in our tree's contrib/ section to give them visibility and users convenience. Now Git ecosystem has grown to have many users who know Git and who do not necessarily come to this list, and with easy-to-use hosting sites where anybody can publish their ware and collaborate with their contributors, giving more visibility angle of contrib/ has outlived its usefulness. When there are multiple third-party tools that address similar needs, there is not much point picking one at random and ship it over others, and shipping all of them is simply crazy. In an ecosystem with flourishing third-party add-ons, their products should and will stand on their own. For completeness, let me point out two other small advantages of contrib: * a tool in contrib can assume that it is being bundled with the corresponding version of Git, and therefore doesn't necessarily have to go to the effort of supporting older versions of Git. * at the source-code level, a tool in contrib can take advantage of some of the Git build/test infrastructure, though I don't know whether they currently do. But my main point is that I think it would be easier to phase out contrib/ if there were a good alternate way of providing visibility to satellite projects. The relevant Git wiki page [1] is the most likely candidate, but it is a bit overwhelming due to its size, it has fallen into disuse because it was broken for such a long time, and it is not prominently linked to from git-scm.com. If it were curated a bit, it would help users find the best ancillary tools quickly. Perhaps ranking the tools based on the results of the Git user surveys would help bring the most popular to the top of each category. Michael [1] https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html