Junio C Hamano wrote: > [on vacaion, with only gmail webmail UI; please excuse me if this message comes > out badly formatted or gets dropped by vger.kernel.org] > > On Sat, Sep 21, 2013 at 4:56 PM, brian m. carlson > <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Sat, Sep 21, 2013 at 05:52:05PM -0500, Felipe Contreras wrote: > >> On Sat, Sep 21, 2013 at 4:29 PM, brian m. carlson > >> <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > >> > As Junio has also pointed out in the past, there are people who aren't > >> > able to use Ruby in the same way that they are Perl and Python. If it's > >> > announced now, Git 2.0 might be a good time to start accepting Ruby > >> > scripts, as that will give people time to plan for its inclusion. > > In the very beginning, the codebase and development community of Git was > very small. In order to give usability and also easy availability of minimally > sufficient features, we used shell and Perl for quicker turn-around and > implementation and included these Porcelain scripts written in higher level > languages in the same package as the core Git. > > We should look at use of shell and Perl as necessary evil in that context, > not as an enabler for people who do not want to write in C. It is no longer > 2005 and the "enabler" side has a much more suited project for it these days. > > Namely, it is better served by various language-binding efforts around libgit2. > Binding that takes advantage of each specific language is better done over > there, I think. Cf. http://www.youtube.com/watch?v=4ZWqr6iih3s If libgit2 is so good as a library to interact with Git repositories, why isn't Git using it? Because it's not. It is a necessary evil due to the fact that Git developers neglected to write code in a reusable manner so other people could utilize libgit. So somebody else had to step up, so now we have two code-bases. > If anything, I think the core side should be focused on three things > (in addition > to bug-fixes, of course) in the longer term: > > - Defining and implementing necessary improvements to the core on-file and > on-the-wire data structures and the protocols to serve as the canonical > implementation. > > - Moving away from higher-level scripting languages such as shell and Perl. > Recent "clean --interactive" may have added some code that could be > reused for a rewrite of "add -i" (which I think is in Perl), for example. > The minimum "You need to have these to use Git" should be made more > portable by doing *less* in shell or Perl, not by adding more in the higher- > level languages, and certainly not by adding other languages, be it Ruby or > Lua. > > - Giving solid interface to the outside world, e.g. remote-helpers, credential- > helpers API, and let the users and developers that want to use them do their > own projects, without adding things to contrib/. It's interesting how none of these goals reflect what the users want: https://www.survs.com/results/QPESOB10/ME8UTHXM4M 1. Better user-interface 2. Better documentation 3. GUI tools Do you deny this is what users want? Or you just don't care? I'm not trying to antagonize you, I just truly don't understand how something so obvious for so many users just doesn't even factor into your decision making as what needs to be done. > In other words, now the Git user and developer community are strong > and thriving, > we should strive to make the core smaller, not larger, and encourage people to > form more third party communities that specialise in the areas the > participant of > these communities are stronger than those who are involved in the core > (e.g. like > myself, Peff, Nico, Jonathan, etc.). For programs that talk remote-helper or > credential-helper protocols, for example, it is wasteful to have them > in our contrib/ > and have the changes to them go through my tree, with the same coding style > standard applied to the core, which would in the longer term only add > unnecessary overhead to what they want to do and what their effort supply the > users with. Of course, we can make the core smaller, by replacing all the perl/shell scripts with ruby ones. Sure, it would be better if all the scripts were rewritten in C, but that has been going on for years, and there's no end in sight, and not that much progress at all. So, it's fair to say that the rewrite to C is just not going to happen any time soon, and if we accept that, we should accept that an interim solution is needed, because Windows users are important and they are hurting right now, and that solution could definitely be Ruby. Rewriting scripts to C is hard, rewriting them to Ruby is easy, and one of the advantages of rewriting to Ruby, is that having the C->Ruby bindings available would make it easy to replace part of the scripts chunk by chunk, so we could have a half Ruby, half C script, and eventually 100% C. This is a practical solution, it's a realistic path to move forward, not one based on wishful thinking and intentions that never get realized. Once again, the perfect being the enemy of the good in the Git project, even when the good leads to perfect. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html