Both rules were already present under "Visual C++ cache files", where they
have been since the template was created in 2010 (590e423). A second copy
was added in 2019 (e285e4b) under a new "Visual Studio 6 technical files"
heading, whose commit described them as "their purpose is unknown for me".
Beyond being duplicates, the second heading is inaccurate. Neither file is
specific to Visual Studio 6:
- *.ncb is the Visual C++ IntelliSense database, used through Visual Studio
2008 and replaced by the SDF database in 2010. The template already lists
*.sdf two lines below *.ncb in the "Visual C++ cache files" section, so
the pair belongs together there.
- *.aps is the binary form of the resource script used by the resource
editor. Microsoft documents it for msvc-140 through msvc-180 (Visual
Studio 2015 to 2022) and states plainly that it should not be in source
control.
The genuinely VS6-specific rules added by that commit (*.vbw, *.dsw, *.dsp)
are untouched. Behaviour is unchanged: both patterns are still ignored, once
each, under the heading that describes them correctly.
Since TwinCAT 3.1 build 4026.xx, the *.xtv file stores project-specific
mappings and must be tracked in version control. Only the backup and
temporary variants stay ignored.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Claude Code creates git worktrees under .claude/worktrees/ at the repository
root. The official documentation explicitly recommends gitignoring this path
so worktree contents don't appear as untracked files in the main checkout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adding a default `.gitignore` for new R projects is a nice features. Around 20% of CRAN packages contained compiled code, often C/C++ (and increasingly Rust etc). Those packages
will when `git add everything` is used also commit their object code and shared libraries. With this PR they will no longer so it should offer a small quality-of-life improvement to these repositories.
Removes the root version since I can't properly gauge the impact
and widespread use of AL easily. I also did this because the community
version is simpler and more complete in my opinion.
As announced in the devlog https://ziglang.org/devlog/2026/#2026-02-06 all dependencies will now be fetched in the `zig-pgk` directory.
Unless you have a specific reason to include them in your source code, they should be ignored.
Cribbed directly from the Element Flatpak's .gitignore file at
https://github.com/flathub/im.riot.Riot/blob/master/.gitignore, simply
because Element is a pretty popular application.
Note in particular that this covers all directories that will be
created by the Flatpak tutorial's suggested `flatpak-builder` command:
https://docs.flatpak.org/en/latest/first-build.html#build-and-install
`repo` is the OSTree repository that the built Flatpak will be
"published" to for testing, `.flatpak-builder` is an internal build
directory, and `builddir` is another, user-specified build directory.
The current `coverage.*` pattern includes `*.go` files as well. If you use `go vendor`, this causes the following files to be excluded:
- `vendor/golang.org/x/text/internal/language/coverage.go`
- `vendor/golang.org/x/text/language/coverage.go`
This becomes a nightmare to troubleshoot why the local build works, yet a CI fails (as the files were not committed).
Adding `!coverage.go` ensure that `*.go` files do not get accidentally excluded.
Historically R users have used the .Renviron file for storing environmental variables such as secrets, credentials, API keys etc. However, I believe there are several compelling reasons for adding .env to the .gitignore too:
1. The dotenv R package was created to allow users to use .env instead of .Renviron. The package has a significant number of downloads. https://github.com/gaborcsardi/dotenv
2. .env files are standard in many other programming languages. It wouldn't be that out of the unexpected to think R users might end up with an .env file because a python user on their team contributed files to the repo, the R user started programming in nodejs and is used to working with .env file, or a repo is in the process of being translated from a language that uses .env to R.
3. LLMs are making programming accessible to people who may not have much previous experience handling credentials and security. One of the first steps many of these users have to do is store LLM provider API keys somewhere. I worry about a new R user adapting a python workflow or an R workflow that recommends using an .env file and then accidentally committing their LLM API keys to a public repo.
4. I can't think of why an R user would create an .env file for any other reason other than storing credentials and environmental variables. If, for whatever reason, they need to commit an .env file, they can remove that part from the template, but I think the risk of accidentally exposing sensitive credentials justifies adding .env files to the template and not commenting it out by default.
Remove Boss dependency manager vendor folder from ignore. This is interfering with projects that contains a "modules" folder regardless of Boss dependency being present.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Devin Dooley