Paths on the working tree are left alone. ours, -theirs, -merge or -conflict is specified. When restoring files on the working tree from the index, do notĪbort the operation if there are unmerged entries and neither Now, let's look at the man page entry to see why this fantastic tool won't do what I am telling it to do: -ignore-unmerged Now I have to go investigate whether the operation was actually performed or not (hint: it wasn't). At least it should say the operation was not performed. But with this kind of user interface, I stand by the 'bug' moniker: % git restore LEGALįirst the minor issue: when a tool refuses to do something because of a particular condition, it's not just a warning. Yes, I know some git-head is going to say, 'It's not a bug, it's by design'. Great, that sounds reasonable - a nice simple purpose-built tool for a common operation.īut, here's my new 'favorite' git bug. So, remember: HEAD vs target commit.In recent git versions, git restore is supposed to be a 'better' way to revert undesired local changes than the overloaded checkout.

The same change is applied on both histories.Īnd that is without considering cases like moving backward/forward in history.

There was a commit and then a revert on the file on the target branch history.

A file can be the same (content) and still have commits in the target branch history under many different circumstances. Which, somebody might say, is the same as what it says in the accepted answer, right? Well, not really.

If, however, at least a modified file is not the same between HEAD and the target commit / branch then git refuses to checkout because it would require a merge to be able to move to that place. If the files are the same, git has no problem checking out and keeping the files as you have them in the working tree. It's all dependent on if the modified files are the same between HEAD and the target commit. What git considers is not really if there are changes on the modified files on the target branch / commit since last merge-point. The explanation in the accepted answer from Keltar is very good (and I have upvoted it), but I want to give a different answer because I do not think it is accurate. Otherwise, your other option is to abandon your current branches changes with:.Then cherry pick the other commit: git cherry-pick Then checkout to the desired branch git checkout Make sure your branch is up to date: git fetch Then discard unwanted changes: git checkout.

If the desired branch isn't new you can either cherry pick a commit and fix the conflicts or stash the changes and then fix the conflicts.Ĭopy the sha of your commit. You should also remove dependencies which may also conflict with the destination branch.įor example, for iOS developers: pod deintegrate If you are seeing this error when you try to switch to a new branch, then your current branch is probably behind one or more commits.

This error happens when the branch you are switching to, has changes that your current branch doesn't have. If I do git status, I get No changes to commit I thought that I should remove the file from the staging area: git reset HEAD src/Pro/ConvocationBundle/Controller/DefaultController.phpīut I'm getting the same error. Please, commit your changes or stash them before you can switch branches. Src/Pro/ConvocationBundle/Controller/DefaultController.php So if I'm working on staging and I see an error, I change to master branch: git checkout masterĪnd then I merge with both branches: git checkout stagingĪnd doesn't matter if there are other files on the working tree.īut now, when I try to change to the master branch, I'm getting an error: error: Your local changes to the following files would be overwritten by checkout: I develop on staging, and use the master branch to fix bugs. I have a project with two branches: staging and beta. This question is similar to this one, but more specific.

Abort git stash pop