Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 15, 2016, 16:57 UTC
Message-ID: <xmqq4m6mhsvj.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqk2fihv90.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 14 quoted lines

> Johannes Schindelin <johannes.schindelin@gmx.de> 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.