Revert "Ignore all .dot files"

[GrahamCampbell]

Reverts #226

[sanmai]

If you want to add them, git add -f and you never need to think again about yet another .something to the .gitignore.

[GrahamCampbell]

This is very much not usual practice.

[GrahamCampbell]

I asked ChatGPT to do some deep research on this.

---

Why Using .?* in .gitignore is Problematic

Using the pattern .?* in a .gitignore – which matches any file or directory beginning with a “.” (dot) and at least one character after it – effectively tells Git to ignore all dotfiles. This broad rule may seem convenient for hiding clutter, but it’s widely considered bad practice. It can unintentionally exclude important files from version control, undermining collaboration, version history, and repository integrity. Below we examine what .?* catches, why that’s dangerous, and how to safely ignore only what you intend.

What .?* Matches in .gitignore

In Git’s ignore glob syntax, * matches any sequence of characters (except directory separators), and ? matches exactly one character. The pattern .?* thus means:

• A literal dot . followed by at least one character (due to ?), then any characters (*) after that.

In practice, .?* will match virtually every “dotfile” or hidden file in the repository. For example:

• .gitignore (dot + “g” + “itignore”) – matches because it starts with .g…

• .env (dot + “e” + “nv”) – matches

• .git directory (dot + “g” + “it”) – matches (though .git/ is a special folder; see below)

• .editorconfig, .eslintrc, .babelrc – all match (dot + one char + rest)

• Any filename beginning with . and at least one more character (.a, .bash_profile, .config/, etc.)

Essentially, .?* behaves like a catch-all for hidden files. The only things it doesn’t match are the literal entries . and .. (current and parent directory), which are not normal files anyway. This means nearly every configuration or metadata file that starts with a dot will be ignored by Git if this pattern is in your .gitignore.

Unintentional Exclusions Caused by .?*

Because .?* is so broad, it can ignore many critical files and directories that you typically do want in version control. Here are some examples of dotfiles commonly needed in a repo and what happens if they’re ignored:

Dotfile / Directory	Role in the Project	Consequences if Ignored
.gitignore	Lists ignore rules shared across the team.	Not tracked: Teammates won’t have the same ignore patterns. This leads to inconsistent builds and accidental commits of files that one person ignored locally. In practice, .gitignore is meant to be versioned because it’s “useful for everyone who wants to work with the repository”.
.git/ (Git directory)	Stores Git repository data (version history, config). Not a file to commit – Git automatically excludes this.	Redundant entry: Including .git in .gitignore has no effect (Git never tries to add its own .git folder). However, it can confuse developers; listing it indicates a misunderstanding. (If someone tried to force-add a .git folder inside a subdirectory, ignoring it might hide a serious issue.)
.env files	Environment variables (often secrets or config for local dev). Usually you do want to ignore actual secret .env files.	Mixed outcomes: Ignoring secrets is good, but .?* also ignores any file starting with “.env”. This means a template like .env.example (commonly included to show required env vars) will be ignored too. The team may lose the example file, leaving others unsure what variables to set. It’s better to ignore only real secret files (e.g. .env and maybe .env.local) and not ignore safe sample files.
.gitattributes	Defines repository settings for file handling (e.g. end-of-line normalization, diff settings).	Not tracked: Cross-platform settings are lost. For example, without .gitattributes, Windows vs Unix line-ending differences might not be handled, causing inconsistent behavior. Other custom attributes (like marking binary files or linguist language stats) would also be absent. Overall, repository behavior can diverge across machines.
Project config files (various)	Many tools use dotfiles for configuration: .editorconfig (editor formatting rules), .eslintrc, .prettierrc, .stylelintrc, .babelrc, etc.	Not tracked: These configs won’t be in the repo. Team members and CI pipelines won’t share the same lint/formatting rules or build settings. For instance, ignoring an .editorconfig means code style may vary by contributor. Ignoring linter configs can lead to code quality issues slipping through since the config wasn’t applied by others.
CI/CD and service files	Continuous integration or deployment configs often start with dot: .gitlab-ci.yml, .travis.yml, or directories like .github/workflows/ (GitHub Actions), .circleci/. Also Docker and cloud configs: .dockerignore, .npmrc (for npm registry settings), etc.	Not tracked: Your CI pipeline or other services may not function. For example, if .gitlab-ci.yml is ignored, GitLab will have no pipeline definition. Ignoring a .dockerignore might bloat your Docker context because the file wasn’t there to exclude files. In short, essential infrastructure/configuration will be missing from the repository, breaking automation and deployments.
Web server files	Files like .htaccess (Apache config) or .well-known/ directories (for SSL/identity) start with dot.	Not tracked: These files control behavior in production. If they’re ignored and not deployed, features can break or security rules might not apply. For instance, a missing .htaccess could leave a site misconfigured.
Placeholder files	Files used to mark directories for Git: e.g. a blank file named .gitkeep or .keep. These are dotfiles by convention.	Not tracked: The empty directory you meant to include in the repo will actually remain empty and untracked. Teams often add a .gitkeep to version-control an otherwise empty folder. If .gitkeep is ignored, the folder may accidentally be omitted from commits entirely, defeating the purpose.

The upshot: a blanket rule like .?* can hide virtually any configuration, metadata, or documentation file that happens to start with a dot – including the very rules file (.gitignore) meant to control ignoring. Some of these files are critical for consistent collaboration (e.g. shareable configs and CI files), and others, while meant to be ignored (like secrets), should be handled with more nuance to avoid collateral effects. It’s no wonder that maintainers note “it’s a bad practice to exclude dotfiles” by default.

Consequences for Collaboration and Version Control

Ignoring important dotfiles harms collaboration and repository integrity in several ways:

• 🔃 Loss of Shared Settings: Key config files missing from the repo means developers might use different settings. For example, if a linter config or .editorconfig isn’t checked in, each contributor’s environment may enforce different coding standards. This leads to inconsistent code style and “it works on my machine” problems.

• 🤝 Inconsistent Ignore Rules: If .gitignore itself is ignored and not in the repo, each contributor might have different untracked files. One dev might be ignoring certain build artifacts while another unknowingly commits them. A Stack Overflow answer emphasizes that .gitignore should be committed because “normally yes, .gitignore is useful for everyone who wants to work with the repository”. Not sharing it undermines the whole purpose of ignore rules.

• 🚨 Missing Critical Files: Overly broad ignores can cause accidental omission of files that should be in version control, sometimes with serious consequences. For instance, a developer’s global or local ignore rule might hide files that others expect in the repo. One team recounted spending days recovering a repo after discovering that a dev’s ignore patterns prevented several important files from ever being committed. If your .gitignore mistakenly ignores needed files (say, a config or a template), it might go unnoticed until something breaks.

• 🔄 No Change History: Any file ignored from day one has no version history. If you don’t realize a config file wasn’t checked in, team members can’t tell who changed a setting or when. You lose the ability to version and roll back those configurations. This is risky for things like CI configs or deployment scripts – changes won’t be tracked or code-reviewed if the files never enter Git.

• ⚠️ Undetected Differences: In a worst-case scenario, two developers might have different versions of a critical dotfile locally, each thinking their copy is the “truth” since it’s untracked. This can cause subtle bugs or security issues (imagine one person has a more updated .env or .npmrc that isn’t shared). Because Git is ignoring these files, it won’t warn you about the discrepancy.

• 📦 Broken Builds/CI: When CI/CD config files or environment files are ignored, automated processes can fail. For example, if .gitlab-ci.yml never made it into the repo, your project won’t run CI tests or deployments on GitLab. Similarly, ignoring a file like .npmrc that contains registry credentials could cause dependency installs to fail for other users or in CI. These kinds of issues can be hard to trace back to “oh, our .gitignore rule erased that file from the repo.”

In summary, overly broad ignore rules jeopardize the consistency and completeness of the repository. They can introduce invisible discrepancies between environments and make collaboration error-prone. Git’s documentation advises that patterns meant for all collaborators belong in a tracked .gitignore file – reinforcing that we should share ignore configurations, not keep them local and certainly not ignore the ignore file!

Best Practices: Ignoring Dotfiles Safely

To avoid the pitfalls of .?*, prefer targeted ignore rules and maintain a clear, collaborative .gitignore. Here are some best practices:

• 🎯 Use Specific Patterns: Only ignore the files you truly want untracked. For instance, if the goal is to ignore environment secrets, add an explicit rule for .env (and maybe .env.local or other variants your workflow uses). Do not use a blanket .* or .?* for this. This way, you won’t accidentally ignore similarly named files that should be kept. (For example, many project templates include a .env.example for others to copy – you can ignore .env but commit .env.example so others know what to do. In one case, a starter template that ignored all .env* files also ended up ignoring the .env.example file, confusing new users.)

• 🔍 Audit Your Ignore Rules: If you inherit a project or boilerplate that has a broad “ignore all dotfiles” entry, evaluate which files it might be hiding. It’s often better to remove .* or .?* and replace it with granular entries (for example, ignore only .DS_Store, .cache/, or other known unwanted files). Make sure no critical config is being inadvertently ignored. Community consensus is that blindly excluding all dotfiles is risky – “don’t ignore dotfiles by default” without careful consideration.

• ✅ Track Essential Dotfiles: Ensure that important configuration files are versioned. If a dotfile defines how your project builds, tests, or formats code, commit it. This includes .gitignore itself (so everyone shares the same ignore rules), .gitattributes, editor/IDE configs that enforce team standards, and any CI/CD configs. These files are part of your project’s infrastructure and should live in Git. As a rule of thumb, if “all developers will want to ignore [or use]” a certain pattern or setting, it belongs in the repo’s config – not solely on one machine.

• 📋 Use Negation (Whitelist) Carefully: In some scenarios (like managing personal dotfiles or creating a “clean” repository), people do choose an ignore-everything-then-whitelist approach. For example, one strategy is to ignore all files and then explicitly re-include specific dotfiles using ! rules. This can work – an author on Dev.to describes “ignore everything with exclusions” as a way to avoid constantly updating .gitignore for new tools. In that approach, you might see a .gitignore like:

  .*                # ignore all dotfiles by default
  !.gitignore       # but allow the .gitignore itself
  !.editorconfig    # allow specific config files
  !.eslintrc
  !.gitlab-ci.yml
  !.prettierrc
  # ...etc for each needed file
  

  This pattern indeed keeps secrets and unknown dotfiles out while allowing known config in. However, be very cautious with this method: you must maintain the whitelist diligently. Forgetting to whitelist a needed file can cause it to be silently ignored. Always document and double-check which dotfiles are included. For most teams, a simpler approach is just listing the unwanted files (a blacklist) rather than an implicit “ignore all.” Use whitelisting only if you have a clear, controlled list of required files.

• 🌐 Global and Local Ignores: Some files truly don’t belong in any repository, ever (e.g. OS junk like macOS .DS_Store, editor swap files, personal IDE configs). Rather than clutter each project’s .gitignore with these, you can use a global gitignore for your machine. For instance, set core.excludesFile to a global ignore file (like ~/.gitignore_global) and list OS/editor files there. This keeps them out of all repos without needing .?* in each one. Important: Limit global ignores to things that shouldn’t be in any repo (e.g. *.log or .DS_Store). Avoid broad patterns that could exclude real project files; one team learned this the hard way when a dev’s global ignore inadvertently hid important files and “they hadn’t committed several important files due to an ignore”. In short, use global ignores for harmless clutter only, and put project-specific ignores in the project’s .gitignore.

In conclusion, treating all dotfiles as ignore-worthy is overly blunt and can backfire. Dotfiles often carry configuration weight in modern projects. The better practice is to ignore only what you need to: keep secrets and local clutter out, but commit the configuration and metadata files that your software and collaborators rely on. By using precise .gitignore rules (and the occasional !negation or global ignore where appropriate), you ensure that you’re not throwing the good out with the bad. This will preserve your repository’s integrity, make onboarding new contributors easier, and prevent those “mystery issues” that arise from missing files. As Git’s official documentation notes, patterns shared by all developers belong in the repo’s .gitignore – so don’t ignore the very files that hold your project’s together!

[sanmai]

.?* will match virtually every “dotfile” or hidden file in the repository, that's what I want. I can see a wall of text, and I don't see even a single mention of git add -f as if there's no way to override .gitignore on case by case basis. Given that if you ask ChatGPT to explain why the sky can be considered a shade of violet, it will give you a list that is just as long (I wish I was kidding!), I'm not surprised. Let's not continue this.