Reputation: 1991
I've checked out from a remote branch and modified some of the files. However I do not wish to add them in the next commit since they are applicable only to my local configuration; in fact, I always want them to be uncommitted. For that reason, I've applied git update-index --assume-unchanged
on these files. However, now I have problems with checking out from branches where these files differ from my local ones:
If I click on 'Smart Checkout' (which is what I need), it throws an error:
Couldn't checkout origin/master: Your local changes to the following files would be overwritten by checkout:
Even if I click on "Force Checkout" it will throw:
Couldn't checkout origin/master: Entry '.gitignore' not uptodate. Cannot merge.
So how can I check out from other branches, while keeping local changes?
Upvotes: 2
Views: 1810
Reputation: 1067
To checkout the other branch, Git needs to know about the changes, for each file:
git update-index --no-assume-unchanged EACH_FILE
Stash those changes:
git stash save "Save local conf"
You can now checkout to your other branch:
git checkout myotherbranch
Finally, you can restore your local changes if you want them in your other branch:
git stash pop
And, as mentioned by Mark, I'd use --skip-worktree to protect those files from changes. Why? See here
Upvotes: 1
Reputation: 45659
I always steer people away from assume-unchanged
, for exactly this reason. Your best bet is to find a different way to keep your changes out of the repo.
From your error message, it seems the .gitignore
file is one of the files in question. Non-shared/local ignore rules don't belong in .gitignore
; they belong in .git/info/exclude
.
Other cases may have to be dealt with individually. A common case would be local config files. A typical solution is to source-control only a template, with the expectation that developers will create the actual config file locally (at a path that's either ignored or outside the repo work tree).
If you have local/unshared versions of code, I'd start by revisiting the reasons for that. If it's necessary, then the best solution may be to use a build process that lets you swap in code from outside the worktree.
The bottom line is, if you've told git to track the file at a path, it's going to try to do just that.
Upvotes: 3