3 ms·

> So git should refuse to write the file to disk? Yes, since it's /impossible/ for the file to have the same name on Windows as on Linux (or whatever OS was or

> So git should refuse to write the file to disk? 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.

xg15 10y ago
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.
- Lagged2Death 10y ago
  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"? http://stackoverflow.com/questions/2071288/equivalent-in-git-of-hg-cat-or-svn-cat http://stackoverflow.com/questions/2071288/equivalent-in-git...

xg15 10y ago

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.

Lagged2Death 10y ago
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"? http://stackoverflow.com/questions/2071288/equivalent-in-git-of-hg-cat-or-svn-cat http://stackoverflow.com/questions/2071288/equivalent-in-git...