Subject: Re: Non-blob .gitmodules and .gitattributes

From: Junio C Hamano <[email-masked]>
Date: Tue, 18 Jun 2024 13:14:57 -0700

Alexey Pelykh <[email-masked]> 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.