CODEWITHSUNDEEP
git
Fuyu Persimmon
Fuyu Persimmon

Reputation: 483

How to ignore a tracked file locally only

How do I ignore a file locally only, that is already on the index? I don't want to remove the file from the index, thereby affecting others. Things I have tried:

both update-index commands give errors when the file has been modified and trying to switch branches.

$ git checkout myBranch
error: Your local changes to the following files would be overwritten by checkout:
        myFile.json
Please commit your changes or stash them before you can switch branches.
Aborting

This error is because "content safety is still a priority" according to git documentation. Any ideas?

Upvotes: 0

Views: 56

Answers (1)

torek
torek

Reputation: 490168

The question becomes: what do you want to happen to myFile.json when you check out some other commit?

Background

Using --skip-worktree (don't use --assume-unchanged here, it's meant as a speed hack rather than an absolute directive; see Git - Difference Between 'assume-unchanged' and 'skip-worktree') tells Git that it should not be too concerned about the modifications to the work-tree file. But ... they are modifications to the work-tree file. Let's say the path for this file is P. Git leaves the index version matching the HEAD commit—lets say that this is, or will be by the time we're looking at it, commit ID 1234567. The work-tree version changes, and when you do various Git operations, it "skips the work-tree version" and just keeps using the index version of P. This lets you modify the work-tree P, and even make new commits if you like, using the (unchanged) index version of P.

In any case, your work-tree version of P no longer matches your index version of P. You are, as we noted, now on commit 1234567, i.e., git rev-parse HEAD produces that hash ID.

Now, though, we find that for Git to check out the other commit, i.e., to move HEAD from commit 1234567 to commit fedcba9 or whatever, Git will have to replace or remove the index version of P. It could do that, but as it's currently coded, that would also replace or remove the work-tree version of P.

(Switching to some other other commit, such as say 8888888—a very lucky commit in China—might not need to touch the index version of P. In this case, git checkout would be happy to switch HEAD to that commit, and then afterward, back to 1234567 again. But fedcba9 is not so lucky.)

It's "safe" to replace or remove a work-tree version of P if and only if the index version of P matches the HEAD version of P, since then you can get that version of P back from the old HEAD, i.e., from 1234567 in our example. But we've already declared that the work-tree version of P doesn't match the HEAD version. The --skip-worktree flag does not change the (un)safety of this operation; it just means that various other operations don't complain that the work-tree version doesn't match the index version.

So, what do you want to happen to P?

You're sure, at this point, that you want to move from commit 1234567 to commit fedcba9.

Commit 1234567 holds a version of P, and your index version of P matches that. Your work-tree version of P does not.

Commit fedcba9 holds a different version of P or says that P should no longer exist, and your index version of P does not match that.

Checking out fedcba9 will put fedcba9's version of P into the index, or remove P from the index. Either action should replace-or-remove the work-tree version of P as well so that you can see what's in (or not on) fedcba9. It's definitely not the same as what's in 1234567.

Would you like to see that version of that file? If so, save the current work-tree contents of P elsewhere, restore P to what's in the index / HEAD commit, and then check out fedcba9. You will now see, in the work-tree, what's in fedcba9. Your saved-elsewhere P will be safe elsewhere.

Do you not care what's in that version of that file, and want to retain what's there now? If so, save the current work-tree contents of P elsewhere, restore P to what's in the index / HEAD commit, and then check out fedcba9. Then overwrite whatever is in the work-tree with your saved-elsewhere copy.

Git won't choose either of these for you, but it's easy to do yourself. You just need to decide which one, and then do it.

Upvotes: 2

Related Questions