{"thread":{"id":"63959","subject":"Implement feature to link/include other gitignore files in gitignore","startedAt":"2025-08-13T21:09:53Z","lastAt":"2025-08-13T21:50:01Z","messageCount":2,"participants":["Ryan Johnson","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"524152","messageId":"LV8P220MB2017EA88974F2311DCFB7665F52AA@LV8P220MB2017.NAMP220.PROD.OUTLOOK.COM","threadId":"63959","inReplyTo":null,"subject":"Implement feature to link/include other gitignore files in gitignore","fromName":"Ryan Johnson","fromEmail":"rj.amdphreak@gmail.com","sentAt":"2025-08-13T21:09:50Z","receivedAt":"2025-08-13T21:09:53Z","isPatch":false,"sender":{"key":"rj.amdphreak@gmail.com","avatar":null},"body":"Feature request:\n\nLet .gitignore file link/include other gitignore files:\n\n```\ninclude .gitignore.python\n```\n\nWhy 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.\n\nRespectfully, consider adding this easy effective idea.\n"},{"id":"524156","messageId":"aJ0IgPBaJrOMr1q6@fruit.crustytoothpaste.net","threadId":"63959","inReplyTo":"LV8P220MB2017EA88974F2311DCFB7665F52AA@LV8P220MB2017.NAMP220.PROD.OUTLOOK.COM","subject":"Re: Implement feature to link/include other gitignore files in gitignore","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-08-13T21:49:52Z","receivedAt":"2025-08-13T21:50:01Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-08-13 at 21:09:50, Ryan Johnson wrote:\n> Feature request:\n> \n> Let .gitignore file link/include other gitignore files:\n> \n> ```\n> include .gitignore.python\n> ```\n> \n> Why would this help?\n> https://github.com/github/gitignore/blob/main/Python.gitignore Look at\n> how long that Python gitignore is. If I am developing a project with\n> multiple languages, imagine how long and how many duplicates will show\n> up when I copy templates from these other languages:\n> https://github.com/github/gitignore . Now imagine a team of people\n> adding new gitignore patterns. They will inevitably add them somewhere\n> I don't want, like in the middle of templates. I don't want people\n> editing the templates, because it's too difficult to see their changes\n> vs the template. I want the templates to be linked so that we can tell\n> people to copy updated gitignore templates, without having to analyze\n> the file for lines that are custom-made.\n> \n> Respectfully, consider adding this easy effective idea.\n\nI don't have a strong opinion on this idea, but let me provide some\ncontext on why it may not have been implemented yet.\n\nFirst, doing that is an incompatible change.  The include directive you\nspecified matches the file \"include .gitignore.python\", which is a valid\nfilename on Unix.  Even if you think that is a bizarre thing to name a\nfile and that we can break that case, I assure you that people name\ntheir files in many bizarre and nonsensical ways and do many strange\nthings and we still try not to break them wantonly.\n\nSecond, lots of things read the `.gitignore` file and will have to be\nupdated with the new syntax: other implementations, like libgit2;\nsoftware that uses them, like Rust's Cargo; tools like rsync, which\nparse these values to decide what should be transferred and what should\nnot; tools in the Git ecosystem like Git LFS; and so on.\n\nThird, most projects do not use giant templates like the one you linked\nas they stand.  It is unlikely that most Python projects use all of the\ntools in that gitignore file, so most projects can deal with a much\nsmaller subset of that file.  Newer languages, like Rust, put all of\nthe generated files in a small number of directories so that they can\nbe easily ignored.  Most of the projects I've dealt with only ignore\nthose specific patterns that are necessary to exclude build products\nfrom being checked in, so they tend to be relatively small.\n\nFor instance, Git, which has the style of building everything in the\nroot of the repository, has only 256 lines.  Many build systems place\neverything in one directory, so ignoring things (and cleaning up with\n`make clean` or the like) becomes easy. libgit2 does this and has only 8\nlines of gitignore, 6 of which are editor or OS cruft that people should\nbe putting in their own personal `$XDG_CONFIG_HOME/git/ignore` files and\nnot in the project's gitignore.\n\nSo I don't doubt that this feature could in fact be useful for quite a\nfew people and I certainly wouldn't be opposed to seeing an\nimplementation of some variant of it, but in general, most projects\nstructure their code in such a way that it ends up not being a feature\nthey need.  I do, however, disagree that it is \"easy\".\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"}]}