{"thread":{"id":"63388","subject":"Feature Request: Support character escapes in .gitignore","startedAt":"2025-05-03T09:14:46Z","lastAt":"2025-05-03T09:14:46Z","messageCount":1,"participants":["Jordan Macdonald"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"517169","messageId":"CAAg4dd0b8q6cGnk+bEbomCRkBX2PkG7q15YK+DkngMJaq84pYg@mail.gmail.com","threadId":"63388","inReplyTo":null,"subject":"Feature Request: Support character escapes in .gitignore","fromName":"Jordan Macdonald","fromEmail":"macdjord@gmail.com","sentAt":"2025-05-03T09:14:34Z","receivedAt":"2025-05-03T09:14:46Z","isPatch":false,"sender":{"key":"macdjord@gmail.com","avatar":null},"body":"Summary: .gitignore rules should support using character escapes to\nmatch for non-printable and non-ASCII characters in paths, e.g. '\\r'\nfor carriage-return.\n\nBackground: After a recent incident in my project where a bunch of\n.DS_store files got accidentally committed to our repo, I decided to\nupdate our .gitignore file to exclude a bunch of common metadata files\nand other cruft.\n\nOne of the files my research turned up as something we would want to\nexclude was MacOS's Icon file (\nhttps://superuser.com/questions/298785/icon-file-on-os-x-desktop ).\nHowever, there was a complication: the full name of these files is\n\"Icon\\r\", i.e. the last character of the file name is a ASCII\ncarriage-return. I look into how to write a .gitignore rule that would\nmatch this, and was distressed to discover the only way to do so would\nbe to have a literal ASCII carriage-return in the .gitignore file.\n\nNow, including a literal carriage-return in the file was undesirable\nfor a number of reasons:\n- There are a number of tools in our dev environments (various\ndifferent editors, linters, even Git itself with the 'core.whitespace'\nand 'core.autocrlf' options) which might incorrectly warn about the\ncarriage-return as a line-break of the incorrect type, or worse try to\n'fix' it automatically\n- Most editors would either display it as nothing at all or as a\nline-break, either of which would be misleading and make it easy to\nbreak while editing the file\n- It is just a bad idea in general  to have ASCII control characters\nis a text file if you aren't using them for their control-character\npurpose\n\nThe workaround I ended up using was to add a rule, 'Icon?', which\nignored 'Icon' followed by any one character, then another rule,\n'!Icon[ -~]`, which un-ignored 'Icon' followed by any printable ASCII\ncharacter. (This had the minor side-effect of causing git to also\nignore any file named 'Icon' followed by a control character other\nthan carriage return, and the more major side-effect of causing git to\nignore any file named 'Icon' followed by a non-ASCII character.)\n\nThe proper solution would instead be for .gitignore to have some\nmechanism to include non-printable characters in a rule without\nrequiring those characters to literally be in the file. .gitignore\nalready supports using backslash as an escape character to disable the\nspecial effects of certain punctuation characters (e.g. *, [, leading\n! or #), so the obvious choice is to enable its use for character\nescapes as well. (I'd suggest borrowing the list of escapes used by\nPython ( https://docs.python.org/3.11/reference/lexical_analysis.html#escape-sequences\n).)\n\nOne potential issue: ensuring this does not break compatibility by\nchanging the function of existing .gitignore files. The .gitignore\ndocumentation doesn't define the semantics of a backslash applied to a\nnon-special character, so I'm not sure what the current behaviour is.\nOne option to mitigate the issue would be to only enable these escapes\ninside [character classes], which would reduce the probability of\ntriggering it accidentally at the cost of making it a bit more\ncumbersome to use intentionally.\n\n-- \nSo many books, so little time... - Anon.\n\nYou haven't lived\n'Till you've heard the floor ring\nTo the whoop and the call\nOf 'Balance and swing!'\n"}]}