Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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

+8
−0

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?

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

1 answer

+2
−0

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
History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »