Resync git repo with new .gitignore file

Question

Is it possible to "refresh" a git repository after updating the gitignore file?

I just added more ignorations(?) to my gitignore and would like to remove stuff already in the repo matching the new file.

Amphictyon

Isn't this similar to https://mcmap.net/q/11541/-ignore-files-that-have-already-been-committed-to-a-git-repository-duplicate? – Banker

Could be, would that solution delete already commited files matching the new gitignore? – Immethodical

+1 for inventing the word "ignoration". – Kessler

Possible duplicate of Ignore files that have already been committed to a Git repository – Surety

en.wiktionary.org/wiki/ignoration @AasmundEldhuset it's official – Reichard

@user770: Today I learned! – Kessler

Possible duplicate of How to make Git "forget" about a file that was tracked but is now in .gitignore? – Allan

Answer 1

The solution mentioned in ".gitignore file not ignoring" is a bit extreme, but should work:

# rm all files
git rm -r --cached .
# add all files as per new .gitignore
git add .
# now, commit for new .gitignore to apply
git commit -m ".gitignore is now working"

(make sure to commit first your changes you want to keep, to avoid any incident as jball037 comments below.
The --cached option will keep your files untouched on your disk though.)

You also have other more fine-grained solution in the blog post "Making Git ignore already-tracked files":

git rm --cached `git ls-files -i --exclude-standard`

---

Bassim suggests in his edit:

Files with space in their paths

In case you get an error message like fatal: path spec '...' did not match any files, there might be files with spaces in their path.

You can remove all other files with option --ignore-unmatch:

git rm --cached --ignore-unmatch `git ls-files -i --exclude-standard`

but unmatched files will remain in your repository and will have to be removed explicitly by enclosing their path with double quotes:

git rm --cached "<path.to.remaining.file>"

Banker

I have found that the git add step is unnecessary, when I run git status after git rm --cached , the removed files are already in the staging area and you can just go ahead and commit them. – Flirtation

I just ran this, lost all of my uncommitted changes, and nearly announced my resignation from my job. The accepted answer on this thread saved my life: https://mcmap.net/q/11543/-how-to-revert-a-quot-git-rm-r-quot – Scheldt

@jbal I am sorry for this bad experience, but also confused: did you keep the --cached option? This option ensures the files remain (untouched) on your disk, meaning your changes should have still been there. – Banker

@Banker sorry, that wasn't meant to be a rant or a stick :) But yes, I used --cached and all of my uncommitted changes were lost when I checked my files. Panicked for a moment but "git reset HEAD" restored my files (but this time without the files I specified in .gitignore, so your solution still worked!) – Scheldt

@Scheldt Great! Is there anything I can add/edit to my answer in order for your kind of experience to not happen again? – Banker

@Banker sure, maybe mention that the user should first commit the changes he wishes to keep, then do your solution. It seems like the second link you posted might have a workaround for that, but frankly it wasn't completely clear to me. Regardless, I still appreciate you posting this answer! – Scheldt

@Scheldt Good. I have added the warning and edited the answer accordingly. – Banker

if only i read one line further before doing this "(make sure to commit first your changes you want to keep, to avoid any incident as jball037" #fml – Narcis

@AidenStrydom Hopefully, jball037's solution helps: https://mcmap.net/q/11543/-how-to-revert-a-quot-git-rm-r-quot – Banker

Answer 2

I might misunderstand, but are you trying to delete files newly ignored or do you want to ignore new modifications to these files ? In this case, the thing is working.

If you want to delete ignored files previously commited, then use

git rm –cached `git ls-files -i –exclude-standard`
git commit -m 'clean up'

Nitroso

What's with the single-quotes here? – Weywadt

This is a very simple why to remove files after I update my .gitignore However it needs a couple of minor updates: `` git rm –cached git ls-files -i –exclude-standard git commit -m 'clean up `` – Markowitz

Answer 3

I know this is an old question, but gracchus's solution doesn't work if file names contain spaces. VonC's solution to file names with spaces is to not remove them utilizing --ignore-unmatch, then remove them manually, but this will not work well if there are a lot.

Here is a solution that utilizes bash arrays to capture all files.

# Build bash array of the file names
while read -r file; do 
    rmlist+=( "$file" )
done < <(git ls-files -ic --exclude-standard)

git rm --cached "${rmlist[@]}"

git commit -m 'ignore update'

Edit: As of version ~2.41.0, git ls-files -i also requires -c.

Internecine

Answer 4

I found a more cautious but manual way to avoid losing your changes if you not have enough experience with GIT.

As same as the official answer, instead of removing everything with the period . you can remove just the new pattern you put in your .gitignore file.

Let's say you want to remove all .bak and .cache files, but you forgot to create or put these patterns in gitignore, here's what you should do after created the gitignore file:

git add .gitignore
git commit -m "Create/change gitignore message"
git push
git rm -r --cached .bak .cache
git add .
git commit -m "My regular commit message"

You can even verify if what you put in gitignore is working by checking every step with git status as follow:

git rm -r --cached .bak
git status
git rm -r --cached .cache
git status
...

If something wrong you could just use git restore {same_pattern_you_use_to_remove} and try again.

But if you have a lot of changes in your new gitignore file, I recommend you folow the official answer with jball037 comment:

git rm -r --cached .
git reset HEAD
# all files will be restored without what was included in the new gitignore
git add.
git commit -m "My regular commit message"
git push

Disappointed

That seems safer than my old answer. Upvoted. – Banker