[git] How do I resolve git saying "Commit your changes or stash them before you can merge"?

I made some updates on my local machine, pushed them to a remote repository, and now I'm trying to pull the changes to the server and I get the message;

error: Your local changes to the following files would be overwritten by merge:

wp-content/w3tc-config/master.php

Please, commit your changes or stash them before you can merge.

So I ran,

git checkout -- wp-content/w3tc-config/master.php

and tried again and I get the same message. I'm assuming that w3tc changed something in the config file on the server. I don't care whether the local copy or remote copy goes on the server (I suppose the remote one is best), I just want to be able to merge the rest of my changes (plugin updates).

Any ideas?

You can try one of the following methods:

rebase

For simple changes try rebasing on top of it while pulling the changes, e.g.

git pull origin master -r

So it'll apply your current branch on top of the upstream branch after fetching.

This is equivalent to: checkout master, fetch and rebase origin/master git commands.

This is a potentially dangerous mode of operation. It rewrites history, which does not bode well when you published that history already. Do not use this option unless you have read git-rebase(1) carefully.

checkout

If you don't care about your local changes, you can switch to other branch temporary (with force), and switch it back, e.g.

git checkout origin/master -f
git checkout master -f

reset

If you don't care about your local changes, try to reset it to HEAD (original state), e.g.

git reset HEAD --hard

If above won't help, it may be rules in your git normalization file (.gitattributes) so it's better to commit what it says. Or your file system doesn't support permissions, so you've to disable filemode in your git config.

Related: How do I force "git pull" to overwrite local files?

Discard the local changes using git reset --hard

Before using reset think about using revert so you can always go back.

https://www.pixelstech.net/article/1549115148-git-reset-vs-git-revert

On request

Source: https://www.pixelstech.net/article/1549115148-git-reset-vs-git-revert

git reset vs git revert   sonic0002        2019-02-02 08:26:39 

When maintaining code using version control systems such as git, it is unavoidable that we need to rollback some wrong commits either due to bugs or temp code revert. In this case, rookie developers would be very nervous because they may get lost on what they should do to rollback their changes without affecting others, but to veteran developers, this is their routine work and they can show you different ways of doing that. In this post, we will introduce two major ones used frequently by developers.

• git reset
• git revert

What are their differences and corresponding use cases? We will discuss them in detail below. git reset Assuming we have below few commits.

Commit A and B are working commits, but commit C and D are bad commits. Now we want to rollback to commit B and drop commit C and D. Currently HEAD is pointing to commit D 5lk4er, we just need to point HEAD to commit B a0fvf8 to achieve what we want.  It's easy to use git reset command.

git reset --hard a0fvf8

After executing above command, the HEAD will point to commit B.

But now the remote origin still has HEAD point to commit D, if we directly use git push to push the changes, it will not update the remote repo, we need to add a -f option to force pushing the changes.

git push -f

The drawback of this method is that all the commits after HEAD will be gone once the reset is done. In case one day we found that some of the commits ate good ones and want to keep them, it is too late. Because of this, many companies forbid to use this method to rollback changes.

git revert The use of git revert is to create a new commit which reverts a previous commit. The HEAD will point to the new reverting commit.  For the example of git reset above, what we need to do is just reverting commit D and then reverting commit C. 

git revert 5lk4er
git revert 76sdeb

Now it creates two new commit D' and C', 

In above example, we have only two commits to revert, so we can revert one by one. But what if there are lots of commits to revert? We can revert a range indeed.

git revert OLDER_COMMIT^..NEWER_COMMIT

This method would not have the disadvantage of git reset, it would point HEAD to newly created reverting commit and it is ok to directly push the changes to remote without using the -f option. Now let's take a look at a more difficult example. Assuming we have three commits but the bad commit is the second commit. 

It's not a good idea to use git reset to rollback the commit B since we need to keep commit C as it is a good commit. Now we can revert commit C and B and then use cherry-pick to commit C again. 

From above explanation, we can find out that the biggest difference between git reset and git revert is that git reset will reset the state of the branch to a previous state by dropping all the changes post the desired commit while git revert will reset to a previous state by creating new reverting commits and keep the original commits. It's recommended to use git revert instead of git reset in enterprise environment.  Reference: https://kknews.cc/news/4najez2.html

Try this

git stash save ""

and try pull again

For me, only git reset --hard worked.

Commiting was not an option, as there was nothing to commit.

Stashing wasn't an option because there was nothing to stash.

Looks like it could have been from excluded files in .git/info/exclude and having git update-index --assume-unchanged <file>'ed some files.

So the situation that I ran into was the following:

error: Your local changes to the following files would be overwritten by merge: wp-content/w3tc-config/master.php Please, commit your changes or stash them before you can merge.

except, right before that, was remote: so actually this:

remote: error: Your local changes to the following files would be overwritten by merge: some/file.ext Please, commit your changes or stash them before you can merge.

What was happening was (I think, not 100% positive) the git post receive hook was starting to run and screwing up due to movement changes in the remote server repository, which in theory, shouldn't have been touched.

So what I ended up doing by tracing through the post-receive hook and finding this, was having to go to the remote repository on the server, and there was the change (which wasn't on my local repository, which, in fact, said that it matched, no changes, nothing to commit, up to date, etc.) So while on the local, there were no changes, on the server, I then did a git checkout -- some/file.ext and then the local and remote repositories actually matched and I could continue to work, and deploy. Not entirely sure how this situation occurred, though a couple dozen developers plus IT changes may had something to do with it.

To keep record of your newly created files while resolving this issue:

If you have newly created files, you can create a patch of local changes, pull in remote merges and apply your local patch after the remote merge is complete as defined step by step below:

1. Stage your local changes. (do not commit). Staging is required to create patch of new created files (as they are still untracked)

git add .

2. Create a patch to keep record

git diff --cached > mypatch.patch

3. Discard local changes and delete new local files

git reset --hard

4. Pull changes

git pull

5. Apply your patch

git apply mypatch.patch

Git will merge changes and create .rej files for changes which are not merged.

As suggested by Anu, if you have issues applying patch, try:

git apply --reject --whitespace=fix mypatch.patch This answer git: patch does not apply talks in detail about this issue

Enjoy your continued work on your feature, and commit your local changes when done.

This is probably being caused by CRLF issues.

See: Why should I use core.autocrlf=true in Git?

Use this to pull and force update:

git pull origin master
git checkout origin/master -f

Asking for commit before pull

• git stash
• git pull origin << branchname >>

If needed :

• git stash apply

Probably

git --rebase --autostash

would help

If you are using Git Extensions you should be able to find your local changes in the Working directory as shown below:

If you don't see any changes, it's probably because you are on a wrong sub-module. So check all the items with a submarine icon as shown below:

When you found some uncommitted change:

Select the line with Working directory, navigate to Diff tab, Right click on rows with a pencil (or + or -) icon, choose Reset to first commit or commit or stash or whatever you want to do with it.

For me this worked:

git reset --hard

and then

git pull origin <*current branch>

after that

git checkout <*branch>

In my case, I backed up and then deleted the file that Git was complaining about, committed, then I was able to finally check out another branch.

I then replaced the file, copied back in the contents and continued as though nothing happened.

git stash
git pull <remote name> <remote branch name> (or) switch branch
git stash apply --index

The first command stores your changes temporarily in the stash and removes them from the working directory.

The second command switches branches.

The third command restores the changes which you have stored in the stash (the --index option is useful to make sure that staged files are still staged).

This solved my error:

I am on branch : "A"

git stash

Move to master branch:

git checkout master <br>
git pull*

Move back to my branch: "A"

git checkout A <br>
git stash pop*

I tried the first answer: git stash with the highest score but the error message still popped up, and then I found this article to commit the changes instead of stash 'Reluctant Commit'

and the error message disappeared finally:

1: git add .

2: git commit -m "this is an additional commit"

3: git checkout the-other-file-name

then it worked. hope this answer helps.:)

WARNING: This will delete untracked files, so it's not a great answer to this question.

In my case, I didn't want to keep the files, so this worked for me:

Git 2.11 and newer:

git clean  -d  -fx .

Older Git:

git clean  -d  -fx ""

Reference: http://www.kernel.org/pub/software/scm/git/docs/git-clean.html

• -x means ignored files are also removed as well as files unknown to git.

• -d means remove untracked directories in addition to untracked files.

• -f is required to force it to run.