- The “Builds” folder pattern would match source code files starting
with “Builds”. Corrected to only match directories with Xojo’s
Builds folder naming convention.
- Removed blank line between comment heading and patterns
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.
/UIElementsSchema is an auto-generated folder created by Unity. It is used in the UI Toolkit.
In Unity discussions, staff have confirmed that this folder can be safely ignored.
https://discussions.unity.com/t/uielementsschema/805120
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