Return to Answer

The fact that the file is in .gitignore and is not being tracked is the problem. It means you are not committing this version of the file. So it is an uncommitted file in your work tree. But there is also an earlier version of the same file in the repo from an earlier time when you did commit it. So a simple pull would overwrite the worktree version and git stops you. And git correctly tells you what your choices are for completing this pull. Listen and obey; choose one:

• Make the version in the index match the version in the work tree, that’s called commit

• Make the version in the work tree match the version in the index, that’s called revert, or you could use restore

• Move the version in the work tree aside, that’s called stash

The long term solution is to git rm --cached this file to remove the old version from the index, and commit and push. Now it won’t be present in the remote’s commit the next time you pull, and so there will be no conflict.

It’s not “tricky”, it’s normal.

The fact that the file is in .gitignore and is not being tracked is the problem. It means you are not committing this version of the file. So it is an uncommitted file in your work tree. But there is also an earlier version of the same file in the repo from an earlier time when you did commit it. So a simple pull would overwrite the worktree version and git stops you. And git correctly tells you what your choices are for completing this pull. Listen and obey; choose one:

• Make the version in the index match the version in the work tree, that’s called commit

• Make the version in the work tree match the version in the index, that’s called revert, or you could use restore

• Move the version in the work tree aside, that’s called stash

The long term solution is to git rm --cached this file to remove the old version from the index, and commit and push. Now it won’t be present in the remote’s commit the next time you pull, and so there will be no conflict.

The fact that the file is in .gitignore and is not being tracked is the problem. It means you are not committing this version of the file. So it is an uncommitted file in your work tree. But there is also an earlier version of the same file in the repo from an earlier time when you did commit it. So a simple pull would overwrite the worktree version and git stops you. And got correctly tells you what your choices are for completing this pull. Listen and obey; choose one.

The long term solution is to git rm --cached this file to remove the old version from the index, and commit and push. Now it won’t be present in the remote’s commit the next time you pull, and so there will be no conflict.

The fact that the file is in .gitignore and is not being tracked is the problem. It means you are not committing this version of the file. So it is an uncommitted file in your work tree. But there is also an earlier version of the same file in the repo from an earlier time when you did commit it. So a simple pull would overwrite the worktree version and git stops you. And git correctly tells you what your choices are for completing this pull. Listen and obey; choose one:

• Make the version in the index match the version in the work tree, that’s called commit

• Make the version in the work tree match the version in the index, that’s called revert, or you could use restore

• Move the version in the work tree aside, that’s called stash

The long term solution is to git rm --cached this file to remove the old version from the index, and commit and push. Now it won’t be present in the remote’s commit the next time you pull, and so there will be no conflict.

The fact that the file is in .gitignore and is not being tracked is the problem. It means you are not committing this version of the file. So it is an uncommitted file in your work tree. But there is also an earlier version of the same file in the repo from an earlier time when you did commit it. So a simple pull would overwrite the worktree version and git stops you.

The long term solution is to git rm --cached this file to remove the old version from the index, and commit and push. Now it won’t be present in the remote’s commit the next time you pull, and so there will be no conflict.

The fact that the file is in .gitignore and is not being tracked is the problem. It means you are not committing this version of the file. So it is an uncommitted file in your work tree. But there is also an earlier version of the same file in the repo from an earlier time when you did commit it. So a simple pull would overwrite the worktree version and git stops you. And got correctly tells you what your choices are for completing this pull. Listen and obey; choose one.

The long term solution is to git rm --cached this file to remove the old version from the index, and commit and push. Now it won’t be present in the remote’s commit the next time you pull, and so there will be no conflict.