I highly suggest using templates from https://github.com/github/gitignore for your project as they tend to include a lot of files commonly found in them - eg .idea folders and so on.
For per-user gitignore, one can set the following config in ~/.gitconfig:
# System-wide gitignore file
# To avoid in-repo repetition for system-specifc garbage files
[core]
excludesfile = ~/.config/git/gitignore
Then your file at ~/.config/git/gitignore can be a normal format, and not need to be stored in repo.
Perfect for system files (.DS_Store...) or editor swap files etc.
That command doesn’t feel safe. It’ll delete anything with `DS_Store` in the name (even if it has other text). Does that even work properly? You’re relying on newlines to separate the files. I can imagine a different IFS easily screwing that up. In the end, you’re invoking three different utilities to do a janky operation which can be done properly with a single one:
I think people should be responsible for the litter of their own tools. If their commits have include any litter it should be rejected as they clearly aren't paying attention. The local gitignore is for project specific files.
I have never once experienced this problem. Mostly because I don't work with people who blindly commit everything without even looking once to see what's in their commit.
Ideally people who have .DS_Store, .vscode, etc. would put them into their own $GIT_DIR/info/exclude files and not pollute the shared .gitignore with stuff from their personal setup.
Common pattern/solution, not a common problem. Feels equal-if-not-more Sisyphean. Also: "Oh no, my collaborative maintenance requires both collaboration and maintenance"
Don't accept people playing with shotgun commits; there, problem(s) solved.
This is a bad idea and if this seems necessary you are interacting with very low quality committers. People who don't even bother reading their own commits do not deserve to get their commits merged.
Also, that gitignore doesn't even work. man gitignore:
• An optional prefix "!" which negates the pattern; any
matching file excluded by a previous pattern will become
included again. It is not possible to re-include a file
if a parent directory of that file is excluded. Git
doesn’t list excluded directories for performance
reasons, so any patterns on contained files have no
effect, no matter where they are defined. [...]
While I don't think we've ever merged a pr with ide files, we do merge the .gitignore part when people put them in their commits which has lead to growth over time...
Interesting. Makes sense for open source. In the workplace for those using common IDEs things like .vscode or .idea can definitely help with consistency or shared project setup. Each has docs which mention which files should or shouldn't be committed. Personally, I just use gitignore.io to generate the file based on my company's tooling and call it good enough.
there's a good reason why this isn't done this way. Git is very open ended but there are .gitignore templates out there. ideally anyone submitting a pull request should be looking at what they're adding. but the real issue here is this:
> Luckily, you realize that you can turn the blacklist of files (the gitignore) into a whitelist, by just ignoring everything and manually un-ignoring desired files.
this will not work and tbh it's fitting a square peg in a round hole. it technically might fit if you shave off the square enough but large repos don't do this, they use a round peg: https://github.com/github/gitignore
If you want to just stop yourself from shooting yourself in the foot in your current checkout and maintain privacy around your own stupidity, you can add patterns to `.git/info/exclude`
I didn't see the con explicitly in the comments. When someone adds a file, they'll have trouble figuring it out why it's not visible in git, or they may not realize an important file is missing if they are adding multiple.
I did not know that it can be used for whitelist (although I probably would have figured it out if I use mainly git for version control, which I don't), although I had not used .gitignore and I used "fossil add" to add the files that I wanted instead, which is also a kind of whitelist.
I did think the blacklist for this purpose was a bad idea anyways, before I saw this, so I used whitelist anyways already. (However, you can use which way you prefer, in case you do not like this, either.)
I think .gitignore design is flawed. If I don't want file to be versioned, I don't want its _mention_ in VCS either.
Of course there is .git/info/exclude, but I'm not sure it's working an already cached (present on remote) files. This is another common use case git handles badly - local changelist. For example having .env file on remote with variable names only to denote structure and filling those out in local without showing these modifications in staging.
Or don't have people in your project that add random files or directories, and can't even explain what they are.
I don't use .gitignore files in projects that I control. A few times I've been tripped up by these things ignoring something that should not have been.
I feel that these files should stay local. I don't want your .gitignore any more than I want your .vimrc or whatever. If you maintain a very messy local repo with lots of extraneous files, and find that this file helps you when you're using git, by all means create one for yourself.
26 comments
[ 0.24 ms ] story [ 43.6 ms ] threadI highly suggest using templates from https://github.com/github/gitignore for your project as they tend to include a lot of files commonly found in them - eg .idea folders and so on.
For per-user gitignore, one can set the following config in ~/.gitconfig:
Then your file at ~/.config/git/gitignore can be a normal format, and not need to be stored in repo. Perfect for system files (.DS_Store...) or editor swap files etc.Don't accept people playing with shotgun commits; there, problem(s) solved.
(git config --global core.excludesfile "$CONFIG/git/ignore")
.gitignore is committed to the repository and should be for files created by the repository that shouldn't appear in 'git status' like build/, etc.
Also, that gitignore doesn't even work. man gitignore:
While I don't think we've ever merged a pr with ide files, we do merge the .gitignore part when people put them in their commits which has lead to growth over time...
https://github.com/rclone/rclone/commits/master/.gitignore
Puts the onus on the committer
> Luckily, you realize that you can turn the blacklist of files (the gitignore) into a whitelist, by just ignoring everything and manually un-ignoring desired files.
this will not work and tbh it's fitting a square peg in a round hole. it technically might fit if you shave off the square enough but large repos don't do this, they use a round peg: https://github.com/github/gitignore
I did think the blacklist for this purpose was a bad idea anyways, before I saw this, so I used whitelist anyways already. (However, you can use which way you prefer, in case you do not like this, either.)
Of course there is .git/info/exclude, but I'm not sure it's working an already cached (present on remote) files. This is another common use case git handles badly - local changelist. For example having .env file on remote with variable names only to denote structure and filling those out in local without showing these modifications in staging.
I don't use .gitignore files in projects that I control. A few times I've been tripped up by these things ignoring something that should not have been.
I feel that these files should stay local. I don't want your .gitignore any more than I want your .vimrc or whatever. If you maintain a very messy local repo with lots of extraneous files, and find that this file helps you when you're using git, by all means create one for yourself.