gitignore redesign proposal

[Ryan Johnson <ryan.johnson.code@gmail.com>]

I have 4 proposed changes to the gitignore feature:

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.

2. 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.

3. Implement gitignore.yaml as an alternative to basic gitignore file, for the following reasons:

  - Ability to include other YAML ignore files
  - Clearer organization

4. Every gitignore file should be initialized with a link to the gitignore templates on GitHub.



Why YAML?

Being able to include other files in a main ignore file is necessary collaborative environments. Teams need two things:

1. 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.

2. 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.

I 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.

This 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.

Thank you,
Ryan Johnson