Junio C Hamano <gitster@xxxxxxxxx> writes: > Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > >> Some file names that are okay on ext4 and on HFS+ are illegal in >> Windows. In order to stay truly platform-independent, Git's source code >> must not contain such illegal file names, even if things just happen to >> work on Linux. > > Good thinking. > > Some tests may have to be skipped on platforms that cannot express > certain paths, but even then they shouldn't ship a file with > pathname that cannot even be checked out (they should instead create > and use such a path, protected behind filesystem specific test > prerequisite). This is a tangent. Adding a check target in t/Makefile is a good first step, but any tree of a project that gets participation from those on different platforms must allow any supported platforms to check it out. The issue is not limited to the t/ hierarchy, but the whole thing. I do not mean to say this patch needs to do more than checking t/ at all, by the way. After all, people send patches without running test-lint so this only means that we as the project must be careful. I wonder if we already have a good mechanism to allow a project and its participants (say, "me") to declare "in this project, pathnames must conform to this rule" and help them avoid creating a tree that violates the rule customized to their project. I guess "write_index_as_tree()" would be one of the central places to hook into and that covers an individual contributor or a patch applier who ends up adding offending paths to the project, as well as a merge made in response to a pull request (unless it is a fast-forward) [*1*]. The pre-receive hook can also be used to inspect and reject an attempt to push an offending tree into the history. Such a mechanism would allow a project that wants participation by folks with case insensitive filesystems to ensure that they do not create a directory that has both xt_TCPMSS.h and xt_tcpmss.h at the same time, for example, but the mechanism needs to allow visibility into more than just a single path when the custom check is made (e.g. a hook run in "write_index_as_tree()" can see all entries in the index to make the decision; if we were to also hook into "add_to_index()", the hook must be able to see other entries in the index to which the new entry is being added). [Footnote] *1* "add_to_index()" could be another place to hook into, and doing so has the merit of catching a breakage sooner, but I suspect that alone may not be sufficient if there are other ways for new entries to appear in the index. -- 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