On Tue, 4 Jun 2013, Junio C Hamano wrote:
Junio C Hamano <gits...@pobox.com> writes:
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
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.
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
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.
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