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

Junio C Hamano [off-list ref] writes:

Johannes Schindelin [off-list ref] writes:

quoted

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.