The problem should be addressed, but the proposed workaround seems strange. So git should refuse to write the file to disk? How am I supposed to use a git repo that contains such problematic files on Windows then?
How would you propose to "use" a git repo that contains files with unrepresentable file names in the first place? It's the repo that's not portable, not git. You'd have the same problem if someone handed you a zip file or tarball.
This was actually an issue with early versions of Servo on Windows: cloning the repository would fail because it contained a file with a # in the name.
MSYS2 (a Cygwin-based platform) does renaming, mapping colons to U+F03A from the Private Use Area (which renders in Explorer like a bullet point). Its git package cloned the repository from the article with no problem, "ls" shows "foo:bar", and "cat foo:bar" works. Opening the file in non-MSYS tools also has no problems with the exotic character.
Yes, since it's /impossible/ for the file to have the same name on Windows as on Linux (or whatever OS was originally used to add it to the repository). And yes, git definitely ought to complain loudly in such a case.
I suppose git could be modified to be aware of alternate data streams, but there would probably still be a discrepancy with the way other tools would present the file (think about how "dir foo*" or "dir foo:bar" would behave for such a file on windows vs. linux).
> How am I supposed to use a git repo that contains such problematic files on Windows then?
Unless the repository is usable without those files, you can't. Unsurprisingly, that's the price of being able to use the same set of files in environments that have different file naming rules.
Complaining loudly and making a repo inaccessible are two different things.
I didn't mean that I should be able to build/run/etc things in the repo that rely on the special filename and magically expect it to work. But my this behavior would make me unable to even look at the repo and perform normal git operations, regardless what it actually contains:
If you interpret "refuse to write the file" as a fatal error, I wouldn't even be able to clone the repo because the clone process would fail.
If you interpret it as non-fatal, I could browse the repo, but would always have a non-clean working set with a "deletion" I cannot undo. This means I cannot pull, rebase or checkout anything. (Unless I actually commit the deletion and remind myself not to push it. On every single branch.)
In no scenario can I access the contents of the file, even if I don't care about the filename at all. Even if I would like to fix the filename issue, I couldn't do so from a Windows pc.
That's why I think a solutions using escaping (and highly visible warnings in git status) are better. Yes, your scripts will still break but you have at least a chance to fix the mess.
I suppose the real question is: if git is happy to create stream "bar" on file "foo," which is arguably correct behavior under Windows, why doesn't "git status" (and everything else) just work correctly with the "foo:bar" file/stream that git created?
Would you be able to see the contents of such files with "git show"?
This is how Tortoise SVN handles SVN paths that are invalid on Windows - it doesn't write the offending file.
You should probably not check out such code on Windows in the first place, but if you accidentally do, then you really need to get loud warnings splashed everywhere.
