[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 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/. 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. For that, defining a good inter-system interface boundary is essential on the core side, but we do not need to (and I do not want to see us on the core side doing) design and implement the other side that talks to us, which people may write in their favorite higher-level languages. We define a reasonably robust object & history transfer mechanism over SSH connection with set of necessary hooks to customize what happens when a push and a fetch is requested, and Sitaram built Gitolite totally outside the core. I think that is the kind of thing we want to see *more* in this community. Was it better if we defined in the core how "hosting" service is to be done and implemented one ourselves? I do not think so. Similarly for Michael Haggerty's iMerge, which was done outside the core. -- 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