Hi Git community,
I’d like to propose a new optional safety feature in Git related to
.gitignore and .gitattributes handling.
[Problem Statement]
Some software ecosystems - such as game development tools (Unity,
Unreal Engine) and other project-based environments - rely on
predefined project folders that include .gitignore and .gitattributes.
These files:
- Exclude large generated files, build caches, and temporary data.
- Configure Git LFS for specific binary asset types.
To minimize interference with the rest of a repository, these files
are often shipped inside each project folder, not at the repo root.
This allows multiple projects or heterogeneous formats to coexist.
However, Git only applies ignore and attribute rules after these files
are staged or committed. In practice, many users copy a project into
an existing repo and immediately run:
> git add .
This stages everything - including an arbitrarily large cache or
binaries that should have been excluded or redirected to LFS. This
causes:
- Bloated history and additional cleanup.
- LFS pointer issues and git workflow disruptions ("encountered files
that should've pointers but weren't" errors for other repo users).
This problem is especially common when:
- Teams copy/import projects frequently.
- Team members include non-engineering roles (artists, designers).
- Tight schedules or manipulation of large amounts of small projects
daily make careful staging problematic.
[Proposed Solution]
Introduce an optional config that requires .gitignore and
.gitattributes to be committed before other files:
> [commit]
> requireIgnoreFirst = true
[Behaviour]
- If the option is set to true and ANY .gitignore or .gitattributes
differ from HEAD (newly added or has changes) and other files are
staged in the same commit THEN the commit fails.
- Enforcement happens at git commit (not git add) to minimize disruption.
- Error message includes a ready-to-use fix:
> Error: .gitignore and / or .gitattributes changes detected and must be committed before committing other files. Please commit them separately first, before adding other changes:
> git reset && git add <path to .gitignore> && git add <path to .gitattributes> && git commit -m <commit message>
The idea is motivated by the [pre-commit](https://pre-commit.com/),
the de-facto standard extension to use for git hooks managements - it
behaves similarly, forbidding to commit anything if
.pre-commit-config.yaml has any changes, requiring it to be committed
first to avoid inconsistencies.
P.S.: this option could potentially be extended to include not just
predefined paths but a list of patterns in a [.gitignore pattern
format](https://git-scm.com/docs/gitignore#_pattern_format), but I see
little incentive to have this customizable as of now - can be
discussed, but the simpler suggested option should be sufficient for
all cases.
Benefits
- Prevents accidental commits of caches or binary artifacts.
- Reduces Git LFS misconfiguration disruptions.
- Minimal intrusion - one local config setting. May be set up globally
for companies / users with many repos.
- Easy to advocate as a solution for the given software product users.
- Zero assumptions about any repo layout or user's local / global git
configuration.
Alternatives Considered
1. Repo-level .gitignore / .gitattributes:
- Requires potentially frequent updates whenever the project's
underlying format is changed (new ignored folder or binary extension
added).
- While less likely - users can still commit root .gitignore changes
together with other project data yet-to-be-ignored - which makes the
problem rarer, but not solved.
- No way to limit settings to specific folders in general, unless
users themselves enforce some naming convention - effect will be
global (see zero assumption point above).
2. Shipped git hooks:
- Requires per-repo setup.
- Not all teams employ git hooks in their workflows - forcing their
usage is likely more overhead than just setting a single option.
- For more advanced git workflows users may already have custom hooks,
and git does not have a concept of hook wrappers / chaining - this
makes it quite hard to provide a self-contained solution provided by
the Software in question.
Additional Motivation
- As mentioned above, such an approach is employed by other widely
accepted tools, such as pre-commit.
- Other similar Git safety settings exist, like
[receive.denyCurrentBranch](https://git-scm.com/docs/git-config#Documentation/git-config.txt-receivedenyCurrentBranch).
- GitHub’s [.gitignore templates
repo](https://github.com/github/gitignore) demonstrates the ubiquity
of project-level ignore files, some of which could definitely benefit
from the current approach, making their effect more local &
manageable.
Contribution
If there is a consensus on the feature and the concept is accepted by
the community - I am willing to contribute an implementation as the
next step.
Thank you for considering this proposal - I am looking forward to
hearing from you!
Best regards,
Kirill Sploshnov (GitHub: NormanXpp)
