Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > 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. It is true that in-tree stuff can go in-sync with the rest, but I think that is irrelevant, as we are discussing a tool in contrib/; if it is part of the core, it deserves that benefit over tools developed out-of-tree (that need to worry about utilizing new features after a version check). After moving tools that we want to keep as a part of core out of contrib/, they will still be in-sync. For those that alternative third-party designs and implementations for solving the non-core problems they try to solve (e.g. ciabot, continuous, blameview) can exist, it would be better for the ecosystem of they compete with their alternatives on the same ground. > 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. That is a very good point. > > Michael > > [1] https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools -- 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