arslancharyev31
arslancharyev31

Reputation: 1991

How to checkout git branch with local 'assume-unchanged' files?

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: enter image description here

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

Answers (2)

saccodd
saccodd

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

Mark Adelsberger
Mark Adelsberger

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

Related Questions