Re: Non-blob .gitmodules and .gitattributes

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

 



On Tue, Jun 18, 2024 at 01:14:57PM -0700, Junio C Hamano wrote:

> 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.

I don't think you even need to "git add" it. Just making it in the
working tree is enough for us to look at it. You probably do need an
actual change in a tracked file for "git diff" to bother looking up
attributes (an alternative is just "git show" on an existing commit).

Interestingly, a directory .gitmodules _does_ complain:

  $ git status
  warning: unable to access '/home/peff/tmp/.gitmodules': Is a directory
  On branch main
  nothing to commit, working tree clean

That's because it uses fopen(), rather than open(). And we have a
wrapper that complains about directories there, triggered by the
FREAD_READS_DIRECTORIES knob in the Makefile. It's set for Linux, but
not for Windows (which is why I suspect Windows might just complain by
itself). We don't see that for ".gitattributes" or ".gitignore" because
those use a raw open() syscall, and Linux is happy to allow it. Arguably
that's a bug, as the intent of that knob is that we'd notice and avoid
trying to read from directories.

So even putting fsck warnings aside, I think it's mostly luck that
having .git* files as directories doesn't produce noisy warnings during
normal use.

-Peff




[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