Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Git-ignoring files with special characters in their names, especially newlines
My actual motivation is to understand the semantics of the .gitignore file syntax in precise detail, for a program which is expected to emulate them as accurately as possible. However, while coming up with test cases I realized an interesting problem.
Suppose, on Linux, I have created a file with a newline in its name:
$ ls fo*
'fo'$'\n''o'
In this example, the actual filename is recorded as 4 bytes long, and the third byte represents a newline in ASCII.
I can't find a way to specify in a .gitignore
file to exclude this file from version control. For example, if I use the pattern fo\no
, it seems to instead exclude files named fono
(even though git status
reports the name of the not-ignored file as "fo\no"
, with the double-quotes). Similarly, if I use fo\\no
, it excludes a file that actually have a backslash and lowercase n in the name. Quoting with either single or double quotes doesn't seem to work; it seems to expect those literal symbols in the filename. And of course it will not work to specify the name using an actual newline, because that would just make two separate entries in the file (to match the file fo
and the file o
).
Do I understand correctly that in the gitignore syntax, a backslash followed by any other character just means the other character (similar to typical regex escaping, rather than string escaping)?
It seems that a gitignore line that ends with a backslash cannot match anything; correct? I tried a foo\
pattern, and it didn't match a file named foo
nor the corresponding file with a trailing backslash in the name (which looks like 'foo\'
in my shell but "foo\\"
in git status
output). Why doesn't Git warn about this?
Do I understand correctly that fundamentally, Git treats the patterns as byte-based, at least on Linux? Thus I could specify, say, a filename and a pattern such that neither is valid UTF-8, and it will match byte-by-byte? The documentation seems rather sparse, and naive about the distinction between bytes and text.
I know that Windows doesn't allow newlines (or several other "problematic" characters) in filenames, but I also know that it allows Unicode in filenames by storing them as UTF-16 - and that Windows versions of Git don't require UTF-16 encoding for the .gitignore
file. What are the semantics of that?
Most importantly: with the gitignore syntax, is it possible to ignore a specific file (i.e. not via a wildcard) which has an embedded newline in its name? If so, how?
1 answer
Hidden in the documentation there's
See fnmatch(3) and the FNM_PATHNAME flag for a more detailed description.
so that's probably the route you should be taking to emulate the behaviour as accurately as possible.
That said, the best I've been able to do is to match the newline with a range from codepoint 9 to codepoint 11:
xxd -r <<<"00000000: 666f5b092d0b5d6f0a" >.gitignore
0 comment threads