Reputation: 906
I want to ignore the file workspace
which is inside the folder .obsidian/
of my git project. I have modified my .gitignore
file with that purpose.
This is my .gitignore file:
.obsidian/cache
.obsidian/workspace
.trash/
.DS_Store
However, I am still getting this message when the file gets changed:
➜ git status
On branch main
Your branch is ahead of 'origin/main' by 2 commits.
(use "git push" to publish your local commits)
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: .obsidian/workspace
no changes added to commit (use "git add" and/or "git commit -a")
I don't know why this is happening or what to do.
Upvotes: 4
Views: 2997
Reputation: 490078
.obsidian/workspace
is a tracked file. A file that is tracked is never ignored.
A tracked file is any file that is in Git's index right now.
Git's index is initially filled in from the commit you check out. So if some file exists in some commit, and you git checkout
that commit or git switch
to it, that file, from that commit, goes into Git's index. It is now in Git's index and by definition, is tracked. Note that Git fills in both its index and your working tree, at the same time, during this checkout / switch operation.
You may manipulate a file that is in Git's index at any time:
Running git add
on some file in your working tree—this is the version of the file that you can see and edit—kicks any existing copy of that file out of Git's index, then puts the working tree version of the file into Git's index. So now the index and working tree copies match. The file is also tracked, since it exists in Git's index.
Running git rm
on some file that is in both Git's index and your working tree, removes the copy of the file from Git's index, and removes the copy of the file from your working tree. The file is now gone entirely and therefore is not tracked.
Running git rm --cached
on some file that is in both Git's index and your working tree, removes the copy of the file from Git's index, but leaves the copy in your working tree alone. The file is now untracked by definition, as it exists in your working tree, but no longer exists in Git's index.
Last—this is redundant but worth noting—if you remove the working tree copy of some file that was in both places, then use git add
on that file, Git will remove the copy from its index. So this has the same effect as git rm
(without --cached
) on that file.
When you run git commit
, Git—at that time—freezes a snapshot copy of every file that exists in Git's index, exactly as it appears in Git's index. These are the files that go into the new commit. So the index always holds the files that you propose to include in your next commit. That's why Git fills in the index from the current commit when you check out that commit: so that the proposed next commit, matches the current commit that you just checked out.1
If you want a file to be ignored, but it's currently tracked, you must remove the file from Git's index. Note, however, that if that file exists in some existing commits, those commits will continue to contain that file. New commits you make, having removed the file from Git's index, will omit the file. Comparing the existing commits to the new commits will show the file as being removed.
If you ever check out one of the older commits that has the file, then switch to one of the newer commits that lacks the file, Git will remove the file—because that's the difference between the older and newer commit! So be careful after removing files that should never have been committed. The existing commits do have the file, even if they shouldn't. Checking out the older, existing commits that do have the file will cause pain in the future.
1There are some special cases here: see Checkout another branch when there are uncommitted changes on the current branch for the gory details.
Upvotes: 6