{"thread":{"id":"64462","subject":"gitignore redesign proposal","startedAt":"2025-11-11T01:02:41Z","lastAt":"2025-11-11T02:04:53Z","messageCount":2,"participants":["Ryan Johnson","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"530497","messageId":"DS0PR03MB7290A11407D68F7F3623FD9CA3CEA@DS0PR03MB7290.namprd03.prod.outlook.com","threadId":"64462","inReplyTo":null,"subject":"gitignore redesign proposal","fromName":"Ryan Johnson","fromEmail":"ryan.johnson.code@gmail.com","sentAt":"2025-11-11T01:02:39Z","receivedAt":"2025-11-11T01:02:41Z","isPatch":false,"sender":{"key":"ryan.johnson.code@gmail.com","avatar":null},"body":"I have 4 proposed changes to the gitignore feature:\n\n1. Integrate a hard-coded .gitignore.local option for quietly ignoring user files. Automatically ignore this file, or require users to exclude it in the main .gitignore.\n\n2. Change .gitignore to just gitignore. This is because gitignore is not a system configuration file. Users are expected to interact with it. Dot-files are typically not user-facing files. They are expected to be hidden on Linux systems, which is inconsistent with the expectation of user interaction. They are entirely avoided on Windows systems for user-facing configuration files. When a user sees \".file\" on Windows, they know they should be using a GUI to edit the config, not hand-hacking. Additionally, dot-files are ambiguous: they could contain key-value pairs or scripts. The point is, don't put essential controls in a room labeled \"For personnel use only\" while expecting customers to go touch it to get anything done. gitignore is fundamentally different from the .git folder in intent.\n\n3. Implement gitignore.yaml as an alternative to basic gitignore file, for the following reasons:\n\n  - Ability to include other YAML ignore files\n  - Clearer organization\n\n4. Every gitignore file should be initialized with a link to the gitignore templates on GitHub.\n\n\n\nWhy YAML?\n\nBeing able to include other files in a main ignore file is necessary collaborative environments. Teams need two things:\n\n1. To be able to include templates that are provided by authoritative sources (such as next.js, zig, unity, etc). Veteran coders know to pull templates from this repository: https://github.com/github/gitignore --- a repository that is not self-evident in any respect for a beginner software developer. Beginners have to just *magically* happen upon the repository or search for gitignore templates in a search engine. This intuition is not a guarantee, so every gitignore file should be initialized by git with a link to that repository to maintain good practice.\n\n2. To be able to organize their gitignores hierarchically. At present, people just randomly stick items in the file, so it's a visual mess that results in duplicates being added. Removing a duplicate doesn't guarantee the removal of the other in very large gitignore files, which can cause problems.\n\nI previously requested an include feature in the existing gitignore parser, but I saw that people are afraid to implement it by modifying the normal gitignore syntax to accommodate. To deal with this, I recommend implementing a YAML alternative to the traditional gitignore file. YAML already has a usable syntax, parser, etc. This extension would exist concurrently to the current gitignore implementation so that it can be adopted gradually.\n\nThis is a totally reasonable path forward to make gitignore robust for collaborative development. You have a good idea and a fail-proof way to introduce it.\n\nThank you,\nRyan Johnson\n"},{"id":"530498","messageId":"aRKZw1h35ZZLkTXh@fruit.crustytoothpaste.net","threadId":"64462","inReplyTo":"DS0PR03MB7290A11407D68F7F3623FD9CA3CEA@DS0PR03MB7290.namprd03.prod.outlook.com","subject":"Re: gitignore redesign proposal","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-11-11T02:04:51Z","receivedAt":"2025-11-11T02:04:53Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-11-11 at 01:02:39, Ryan Johnson wrote:\n> I have 4 proposed changes to the gitignore feature:\n> \n> 1. Integrate a hard-coded .gitignore.local option for quietly ignoring user files. Automatically ignore this file, or require users to exclude it in the main .gitignore.\n\nWhy is this better than $XDG_CONFIG_HOME/git/ignore, which is global and works\nfor all of the user's repositories, or .git/info/exclude, which is per\nrepository and not checked in?\n\nThe former is the ideal place to put things one wants ignored globally,\nsuch as Vim swap files or Emacs backup files, and the latter is suitable\nfor individual projects.  The former can even be installed by one's\ndotfiles so that one's `git status` output is always tidy with regard to\none's editor files.\n\n> 2. Change .gitignore to just gitignore. This is because gitignore is\n> not a system configuration file. Users are expected to interact with\n> it. Dot-files are typically not user-facing files. They are expected\n> to be hidden on Linux systems, which is inconsistent with the\n> expectation of user interaction. They are entirely avoided on Windows\n> systems for user-facing configuration files. When a user sees \".file\"\n> on Windows, they know they should be using a GUI to edit the config,\n> not hand-hacking. Additionally, dot-files are ambiguous: they could\n> contain key-value pairs or scripts. The point is, don't put essential\n> controls in a room labeled \"For personnel use only\" while expecting\n> customers to go touch it to get anything done. gitignore is\n> fundamentally different from the .git folder in intent.\n\nTypically, we hide files and directories used by version control systems\nbecause there are several of them (.git, .gitignore, .gitmodules, and\n.gitattributes).\n\nThis also helps other tools easily not process VCS-specific files by\nproviding an option to skip processing hidden files.\n\nCVS and friends did not use hidden files and it was ugly and unwieldy.\n(In general, we should avoid replicating CVS's mistakes.)\n\n> 4. Every gitignore file should be initialized with a link to the gitignore templates on GitHub.\n\nWe try not to prioritize any particular forge in this project and many\ncontributors work on a variety of different forges.  Even though I am\nemployed by a major forge[0], I end up using several because various\nprojects I would like to participate in are on other forges (even some\nprojects that we use at work).\n\nThere's no reason that the GitHub templates are intrinsically better\nthan any other options and if an objectively better option comes along,\nwe would end up providing suboptimal information.\n\nI'll also note that the GitHub templates tend to be very expansive and\ncover a large variety of files.  The Python file, for instance, covers\nDjango, Jupyter Notebook, IPython, Redis, SageMath, and a variety of\nother things that most Python projects will never use.  Having a very\nlong file with a lot of unused entries worsens performance and makes\nmaintenance of the file much more complicated than necessary, especially\nwhen a project needs custom values as well.\n\n> Why YAML?\n> \n> Being able to include other files in a main ignore file is necessary collaborative environments. Teams need two things:\n> \n> 1. To be able to include templates that are provided by authoritative\n> sources (such as next.js, zig, unity, etc). Veteran coders know to\n> pull templates from this repository:\n> https://github.com/github/gitignore --- a repository that is not\n> self-evident in any respect for a beginner software developer.\n> Beginners have to just *magically* happen upon the repository or\n> search for gitignore templates in a search engine. This intuition is\n> not a guarantee, so every gitignore file should be initialized by git\n> with a link to that repository to maintain good practice.\n\nI have over 13 years of professional software development experience and\neven more non-professional, so I think I would qualify as a veteran\ncoder.  I don't use those files, either at home or at work.\n\nInstead, when creating a project, I add those files and directories that\nare build or intermediate products to .gitignore as one of my first\ncommits and add additional entries along the way.  That way, I know that\nmy values are correct for my project.\n\nNote that I almost always have additional custom files that are not\nlisted in the templates, so I need to edit the file anyway.  I assume\nthat's true for most everyone, but I could be wrong.\n\n> 2. To be able to organize their gitignores hierarchically. At present,\n> people just randomly stick items in the file, so it's a visual mess\n> that results in duplicates being added. Removing a duplicate doesn't\n> guarantee the removal of the other in very large gitignore files,\n> which can cause problems.\n> \n> I previously requested an include feature in the existing gitignore\n> parser, but I saw that people are afraid to implement it by modifying\n> the normal gitignore syntax to accommodate. To deal with this, I\n> recommend implementing a YAML alternative to the traditional gitignore\n> file. YAML already has a usable syntax, parser, etc. This extension\n> would exist concurrently to the current gitignore implementation so\n> that it can be adopted gradually.\n\nI agree that YAML is a very popular option.  However, different parsers\nimplement different versions, so they work differently.  It also has\nsome downsides (`no` is interpreted as false, not \"no\", which is a\nfrequent source of problems for Norway- and Norwegian-related\ninformation).  Some parsers[1] also don't support parsing byte data encoded\nas base64 (the `!!binary` tag), which we would need because Git does not\nrequire filenames to be UTF-8.\n\nOther options, such as JSON or TOML, also don't support non-UTF-8 data\n(and JSON doesn't support comments[2]), so those are also out.\n\n[0] My participation in this list, unless stated otherwise, is in my\npersonal capacity only and I neither speak for my employer nor do they\nspeak for me.\n[1] In my brief few minutes of testing a handful of implementations, I\nfound Perl's YAML::Tiny, which also does not accept `!!str`.\n[2] Before you say, \"But there's this variant of JSON that _does_\nsupport comments,\" that is not standardized and most JSON parsers don't\naccept it, so it is strictly worse than using YAML or TOML in terms of\ncompatibility.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"}]}