Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: >> Look at what we have in the contrib/ area. I think what is common among >> them is that their primary benefit is to enrich user's Git experience. > > ... and many of them is to enrich the user experience using Git with > another tool (shell, text editor, foreign VCS). ... where the amount of the benefit they get does not change regardless of the payload. That is what makes them tool in Git users' toolbox, not shell scripters' or p4 users' toolbox. > Git's _core_ already has some code to show diff hunks for various > languages,... I would have to say that it is an oranges vs squirrels comparison. I do not see a justification to reject an addition of an entry to an array that adds a few strings of regexp to drive the mechanism that is already in core, when it gets compiled in, and it is useless by itself outside Git. Unless the language is something obscure, that is. Read git-latexdiff that is a free-standing 200+ line script again yourself. The use of Git in the script is not more than how you would emulate what you would use "cp -r" in order to populate the old/ and new/ directories if the two versions were stored in the file system outside Git. If you rip the part that deals with "the two versions happen to be stored in Git" out, the remainder deals with parsing the command line, interfacing with latex and reporting the result, none of which is in any way Git specific. That is much larger part of the script, which I view as a clear sign that it is an application to serve the need for LaTeX users better, which happens to be written for the subset of LaTeX users who have their contents in Git. Aren't there LaTeX tools archives that would be a much better home for this tool? -- 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