Re: Subject: [RFC] Add config option to enforce committing .gitignore / .gitattributes before other files

> 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)
>