Re: [PATCH/RFC 0/7] Support for Ruby

[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@crustytoothpaste.net> wrote:

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.