Thread (2 messages) 2 messages, 2 authors, 2025-08-13

Re: Implement feature to link/include other gitignore files in gitignore

From: brian m. carlson <hidden>
Date: 2025-08-13 21:50:01

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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help