Alexey Pelykh <alexey.pelykh@xxxxxxxxx> writes: >> But I'd also suspect that other non-POSIX platforms would see the error >> at open(), and _would_ actually produce an error message. I seem to >> recall running into this before with Windows, maybe? > > Is there an easy way to verify "what on Windows" part? I'd be happy to > help, yet I'm not sure I got it right what to look for. Create a .gitmodules and .gitattributes directory, "git add" it, and perform various operations that want to read them, probably. Even a simple "git diff" should try to consult the attribute system (e.g. because it wants to know if a path needs use custom function header regexp pattern). As Peff said, on Linux and probably on macOS, we will silently ignore such .gitattributes and that is what we want. On Windows we may see "cannot open" error reported and visible to the users. > Surely, reserved names are reserved for some reason. If there's a legit > reason alike cost-to-support, having an objection would be dumb. Yet > if supporting would turn out to be of an effort alike dropping the check > then it would seem having that check brings no value. > > With that said, if those are reserved names, why .gitignore is not reserved? > For consistency at least. We do not bother with ".gitignore" since we see no security implications in that file. But other two whose name begin with ".git" do have some security implications (actually .gitattributes is designed not to have any, but .gitmodules certainly does), so we choose to inspect their sizes, contents, and types. But that raises a few more questions. What to do about our future needs that may conflict the needs of users who want to use names of their choice? If we declare that any name that begin with ".git" is reserved, there will be fewer issues, but do we want to and can we afford to? Also what if we later find security implications in ".gitignore" files and decide to inspect their sizes, contents, and types? The current system not issuing a warning does not give users any guarantee that the future systems won't (even though we try hard to avoid introducing such backward incompatible changes, we are human, too, and we sometimes screw up). Thanks.
