[Global/macOS] Prevent corruption of "Icon\r" rule

[i-to-r]

Fixed #2203 PR.

Reasons for making this change:

Make Icon\r pattern less vulnerable to editors and to auto CRLF → LF conversion on commit. As @spencermathews wrote in #2337 :

Since this ignore rule may be vulnerable to editors that automatically standardize line endings, it seems imperative that updates to this file be done with care or else this rollercoaster seems likely to continue.

Note: the Start..End comment has been added because most editors display Icon[␍] pattern in two lines:

# Start of Icon[\r] pattern
Icon[
]
# End of Icon[\r] pattern

Links to documentation supporting these rule changes:

• How to ignore Icon? in git (Icon[\r])

[revolter]

Bump

[gimbo]

Unfortunately, I can report that at least one relatively popular tool doesn't handle this well either.

I just tried this vs the mixed-line-endings hook for the popular (at least in the python world) pre-commit framework, and sadly it does still replace the CR with an LF, rendering the rule useless.

Now, it's clear that this behaviour is a bug in that hook (as from its name it should obviously only be fixing line endings!), but the fact that this was literally the first tool I tried this with suggests to me that this is still a fragile solution, and that anything involving embedding actual CR characters in a .gitignore file is going to be prone to this issue, leaving the "rollercoaster" in place — at least until/unless proper support for unicode code points is added to gitignore.

So, while this PR is a clear improvement on the current situation, may I suggest that it might be worth considering a less precise but more robust solution not involving actual CR characters?

For example, in the same Stack Overflow thread mentioned by @i-to-r in their comment above, we also have this answer, which suggests an approach like this:

Icon?
![iI]con[_a-zA-Z0-9]

As the author says in that answer, it would be worth expanding the _a-ZA-Z0-9 part for more completeness, but you get the idea.

I'd actually started working on a PR suggesting this when I realised I should check if something similar was already in flight, which led me to this PR.

[Leif-W]

For example, in the same Stack Overflow thread mentioned by @i-to-r in their comment above, we also have this answer, which suggests an approach like this:

Icon?
![iI]con[_a-zA-Z0-9]

As the author says in that answer, it would be worth expanding the _a-ZA-Z0-9 part for more completeness, but you get the idea.

What about Icon\r?, does that work? I was thinking about this last night, and a human or tool may conceivably make a file with other characters besides _a-zA-Z0-9. Rather than go down the rabbit hole of chasing what might be valid, from a set of all available valid characters on HFS+(except possibly NUL, /, and maybe :), what about the relatively safe assumption that ANYTHING (except nothing, hence ? not *) after an Icon\r is considered fair game for ignoring? That way, the \r isn't at the EOL, the ? is. That seemed to work for me.

I don't have MacOS for testing, but was able to ignore in WSL2 Ubuntu, and Android Termux, both of which allow creation of Icon\r\r files and directories (with touch Icon\r\r/foo to ensure git would see non-empty dir). In both cases, despite having Icon\r\r in .gitignore, the Icon\r\r file and folders were NOT being ignored, in either WSL2 Ubuntu, or Android Termux. I am not sure why that was.

One odd thing, files created in WSL2/Ubuntu with \r\r at the end get interpreted a little differently in Windows in the Command Prompt or PowerShell and show up as Icon\357\200\215\357\200\215 which is in octal. If for some reason, someone on Windows needs to work with this file locally, but wants to keep them out of the git repo, then the aforementioned Icon\r? will fail to match. Using hex (shorter to type), I added this to .gitignore echo -e 'Icon\xEF\x80\x8D\xEF\x80\x8D' >> .gitignore, and then checking git status, I find the previously touched Icon\r\r file is now ignored on Windows, under native git-for-windows tools, as well as Cygwin/MSYS, and WSL2/Ubuntu. I realize this may be esoteric, but I mention it for the sake of completeness.

[github-actions]

This PR is stale because there have been no updates in 90 days. It will close after 180 days of inactivity. Leave a comment if you want to keep it open 😄

[Leif-W]

Toptal's "solution" was to do nothing, as there's no easy way, or something, Just pinging with a comment, and also to raise awareness that just because a referenced issue was closed, doesn't mean there was any change or solution.

[Alongazhar]

Nyahlanggan Pada Jum, 30 Mei 2025, 12:35 PG github-actions[bot] < ***@***.***> menulis:

…

*github-actions[bot]* left a comment (github/gitignore#3523) <#3523 (comment)> This PR is stale because there have been no updates in 90 days. It will close after 180 days of inactivity. Leave a comment if you want to keep it open 😄 — Reply to this email directly, view it on GitHub <#3523 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BMI7AEM7YPL2NNQM3L5BF5T3A4ZOVAVCNFSM6AAAAAB6F5ZNXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMJZHE2DANRQHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>