[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
> 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
>> <sand...@crustytoothpaste.net> 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
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
- 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
- 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
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
these communities are stronger than those who are involved in the core
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
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html