Re: [PATCH 1/1] Avoid illegal filenames when building Documentation on NTFS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

>> In addition, your `+` scheme will break on Windows once it uses `git.exe`
>> or any other non-MSYS2 helper...
>
> I am not sure what you mean here.  Is your git.exe disabled not to
> be able to do this: "git.exe add hello+kitty.txt"?  I think that is
> a more grave problem, and not limited to the Makefile in the
> Documentation/ directory.

The reason why I thought it was a more grave problem is because (1)
gets 7648757 out of (2), which gets 2297783817 (that is, among the
2.2 billion paths that appear in various GitHub public repositories,
a tad short of 8 million paths have '+' somewhere):

    (1) SELECT count(*) FROM `bigquery-public-data.github_repos.files`
        where path like '%+%';

    (2) SELECT count(*) FROM `bigquery-public-data.github_repos.files`;

If you drop the technique MSYS2 borrowed from Cygwin to support
these characters NTFS does not like by mapping them to a private
page, wouldn't it mean that these projects cannot be used with Git
for Windows?  Are we going to bug each of these projects to change
their pathnames?

If that is not the case, then that's fine.

FWIW, I am OK with moving away from '+' in *our* project; that is
easy enough to do, and such a change does not have to make the end
result visually less pleasing, as long as we pick a good substitute
suffix.  Is '~' (or ',') allowed on NTFS, for example?  The point of
'+' being short, sweet, and easy to spot, I'd rather not to use
'.<anyword>' if we can avoid it.

Whatever suffix we choose, we need to be aware that the pattern is
not limited to Documentation/ directory, so at least the top level
.gitignore and Makefile in various subdirectories need vetting.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux