Michael Haggerty <mhag...@alum.mit.edu> 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

> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to