Jeff King <peff@xxxxxxxx> writes: > But I also buy the argument that contrib/ is simply a hassle. This > script can live in its own repository somewhere, and handle > announcements and patches on the list. I think the output of this script is largely personal preference, which can be made to a project preference for a project enough of whose participant so desires. For example, I would not be surprised if this appeared next to checkpatch.pl script in the kernel archive. When a project that uses Git to store its sources finds a need to summarize its log in a standardized way that is not produced natively by Git, such a project may add this script to its scripts/ area, just like a project that wants to have a standard way to help its contributors to avoid common style errors a lot more than our "diff" (which only highlights whitespace errors) does may ship checkpatch.pl in it. So in that sense, while I do not mean to say that the script itself must become a standalone project that has only one script in it, I do not think it belongs "our" contrib/, as we do not see a need to standardize its output as the log summary standard we the Git project uses on its own history. On the other hand, your illustration of the needed bits to express this particular output format used by Kyle's script, when polished, does fit in our codebase. We are interested in making it possible for projects and users to do more by using Git with its standard customization features.