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

[Junio C Hamano <gitster@pobox.com>]

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

> 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.