is there a non destructive way (no commit, no changes to the repo) to let .gitignore file itself be really ignored in git version 2.34.1 or later?

Question

is there a non destructive way (no commit, no changes to the repo) to let .gitignore file itself be really ignored in git version 2.34.1 or later?

I've been trying many answers from How can I stop .gitignore from appearing in the list of untracked files? and others.., least the destructive ones that want to change the repository to let it work.

Also, I do not want to use any trick in the global git ignore file, as it is global and I need specific config for a single project.

I am careful, I dont need an app to ex.: force me to not ignore .gitignore for any good reason.

The problem is, I would have to create backup copies of .gitignore outside project folder and revert it before a merge, and restore after that, and doing it is very annoying.

I am coding in a forked repo. I dont want to change that file in my repo as it will be extra trouble to prepare pull requests...

I tried patching git executable and git-gui shell script with ex sed -i -r 's@gitignore@git1gn0r3@' git, but it didnt help. Is the only option to make a non system installation and patch the whole git app to let this simple thing work?

suggestion: if we had a git param like: git --I-Surely-Know-What-I-Am-Doing, it could create a big message on startup saying I should not complaint if something wrong happens and I would be fine with it...

so I have tried putting in .gitignore .gitignore and nothing changed. I also tried placing it at .git/info/exclude and nothing happened.

any tip?

Answer 1

.gitignore can definitely be ignored, but it is not possible in Git to ignore changes to tracked files, so .gitignore cannot be ignored and tracked at the same time. Some people recommend various features of git update-index to try to do that, but the Git FAQ is very clear that doesn't work properly and shouldn't be used.

If you have a .gitignore file that isn't checked in, then you can ignore it by adding .gitignore in .git/info/exclude. However, you'd be better off simply using .git/info/exclude to customize the patterns instead. That's specifically designed to allow you to customize the values and override what's in the repository. The patterns in this file take precedence over .gitignore, so you can add exclusions (starting with !) or regular ignore patterns to customize them as you see fit.

Answer 2

I am coding in a forked repo. I dont want to change that file in my repo as it will be extra trouble to prepare pull requests...

On the contrary, you do want to change that file in your repo! Check in your local changes as temporary commits, which basically are plain old normal commits but with a naming strategy that makes them stand out, and you remove them before making a pull request.

---

So assuming you have worked on some foo feature and are ready to create a pull request. You have up till now worked on one branch foo_feature.work based on the main branch which also contains some temporary commits that should not be part of the pull request.

First you start an interactive rebase to clean up things.

git checkout -b foo_feature foo_feature.work   # New branch for cleaned commits
git rebase --interactive --rebase-merges main

where you trim down

label onto

reset onto
pick 26b113a Started implementing foo
pick 5789e28 ==== debug foo ====
pick aba387b Finished implementing foo
pick 59e614a Improved bar
pick bb839a9 ==== debug bar ====
pick f565932 ==== ignore some log files ====
pick dbcfd2b Removed unused baz
pick 3e632d9 ==== ignore some more files ====

to the following:

pick 26b113a Started implementing foo
pick aba387b Finished implementing foo
pick 59e614a Improved bar
pick dbcfd2b Removed unused baz

git push origin foo_feature

and create the pull request.

---

If this was a one time development thing you could then just delete the foo_feature.work branch. But since you indicate that you revert and restore stuff across merges that is a clear indication that you want to keep those temporary commits for later usage. So then rebase the work branch on top of the cleaned up branch:

git rebase foo_feature foo_feature.work   # In case of conflicts, use KDiff3
# https://github.com/hlovdal/git-resolve-conflict-using-kdiff3

Now you have the following:

After the pull request is merged you can pick up your temporary commits when you start working on the next thing:

git branch -m foo_feature.work next_thing.work
git rebase --onto main foo_feature next_thing.work
git banch -d foo_feature  # Already merged though the completed pull request.

---

Attempting to ignore a whole file that is being tacked by source control is fundamentally flawed because there is no guarantee that it will have either only changes you want to contribute upstream or only changes you do not want to contribute upstream.

What if as part of working with the foo functionality you need to add something to .gitignore that should be included in the pull request, but the file also have some thing you do not want to include? Any attempts to ignore the whole file as such will never work here.

The only sensible solution that always works is to check in those changes as individual commits and then ignore the commits you do not want to have include in the pull request through a cleanup interative rebase.