On 06/05/2013 02:04 AM, Junio C Hamano wrote: > Junio C Hamano <gits...@pobox.com> writes: > >> * fc/contrib-related (2013-06-03) 4 commits >> - contrib: related: parse committish like format-patch >> - contrib: related: add option to parse from committish >> - contrib: related: add support for multiple patches >> - Add new git-related helper to contrib >> >> Waiting for the design review to settle. > > As people may have seen in the discussion on the earlier iteration, > something like this (there may be a room for bikeshedding the name, > though) that takes either a range of changes or set of patches and > finds people who may be able to review them may be a good addition > to our official toolchest. > > http://thread.gmane.org/gmane.comp.version-control.git/221728/focus=221796 > > Right now, "related" is in contrib/ primarily because its design > review phase is not yet finished and because it is in Ruby, which > the rest of the system does not depend on. > > I have some administrative comments on two issues as the maintainer. > > * Do we want to add Ruby dependency? > * Do we want to keep expanding contrib/? > > These have been triggered by "related", but the comments in this > message are not limited to the specific topic (e.g. you can read it > with s/Ruby/<any language we currently do not depend on>/). > > > On Ruby: > [...]
I don't have an opinion on allowing Ruby into the core, except to say that I would personally prefer *some* alternative that is more capable than shell and more modern and self-consistent than Perl. Python, Ruby, and Lua would seem to be the obvious candidates, with the latter being easiest for packagers. > On contrib/: > > 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 > own. For completeness, let me point out two other small advantages of contrib: * a tool in contrib can assume that it is being bundled with the corresponding version of Git, and therefore doesn't necessarily have to go to the effort of supporting older versions of Git. * at the source-code level, a tool in contrib can take advantage of some of the Git build/test infrastructure, though I don't know whether they currently do. But my main point is that I think it would be easier to phase out contrib/ if there were a good alternate way of providing visibility to "satellite" projects. The relevant Git wiki page [1] is the most likely candidate, but it is a bit overwhelming due to its size, it has fallen into disuse because it was broken for such a long time, and it is not prominently linked to from git-scm.com. If it were curated a bit, it would help users find the best ancillary tools quickly. Perhaps ranking the tools based on the results of the Git user surveys would help bring the most popular to the top of each category. Michael [1] https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
