On 2025-08-13 at 21:09:50, Ryan Johnson wrote: > Feature request: > > Let .gitignore file link/include other gitignore files: > > ``` > include .gitignore.python > ``` > > Why would this help? > https://github.com/github/gitignore/blob/main/Python.gitignore Look at > how long that Python gitignore is. If I am developing a project with > multiple languages, imagine how long and how many duplicates will show > up when I copy templates from these other languages: > https://github.com/github/gitignore ;. Now imagine a team of people > adding new gitignore patterns. They will inevitably add them somewhere > I don't want, like in the middle of templates. I don't want people > editing the templates, because it's too difficult to see their changes > vs the template. I want the templates to be linked so that we can tell > people to copy updated gitignore templates, without having to analyze > the file for lines that are custom-made. > > Respectfully, consider adding this easy effective idea. I don't have a strong opinion on this idea, but let me provide some context on why it may not have been implemented yet. First, doing that is an incompatible change. The include directive you specified matches the file "include .gitignore.python", which is a valid filename on Unix. Even if you think that is a bizarre thing to name a file and that we can break that case, I assure you that people name their files in many bizarre and nonsensical ways and do many strange things and we still try not to break them wantonly. Second, lots of things read the `.gitignore` file and will have to be updated with the new syntax: other implementations, like libgit2; software that uses them, like Rust's Cargo; tools like rsync, which parse these values to decide what should be transferred and what should not; tools in the Git ecosystem like Git LFS; and so on. Third, most projects do not use giant templates like the one you linked as they stand. It is unlikely that most Python projects use all of the tools in that gitignore file, so most projects can deal with a much smaller subset of that file. Newer languages, like Rust, put all of the generated files in a small number of directories so that they can be easily ignored. Most of the projects I've dealt with only ignore those specific patterns that are necessary to exclude build products from being checked in, so they tend to be relatively small. For instance, Git, which has the style of building everything in the root of the repository, has only 256 lines. Many build systems place everything in one directory, so ignoring things (and cleaning up with `make clean` or the like) becomes easy. libgit2 does this and has only 8 lines of gitignore, 6 of which are editor or OS cruft that people should be putting in their own personal `$XDG_CONFIG_HOME/git/ignore` files and not in the project's gitignore. So I don't doubt that this feature could in fact be useful for quite a few people and I certainly wouldn't be opposed to seeing an implementation of some variant of it, but in general, most projects structure their code in such a way that it ends up not being a feature they need. I do, however, disagree that it is "easy". -- brian m. carlson (they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
