0

Whenever I try to switch to another Git branch in Eclipse this error occurs:

"Checkout Conflicts" constantly appears

Neither stashing or resetting the conflicts solves the problem. The window disappears then and comes back just seconds later.

When pressing on cancel the window disappears permanently but the branch won't be switched then.

I don't want to check in the .project file. Disabling build automatically in Eclipse doesn't work either. The behaviour occurs in both Luna and Mars.

How can I solve this problem?

Zoe
  • 27,060
  • 21
  • 118
  • 148
Harold L. Brown
  • 8,423
  • 11
  • 57
  • 109
  • 1
    Your problem is that you commited one time this file, but eclipse is changing it frequently. Do not commit local configurations and settings of your IDE. – Rene M. Jul 16 '15 at 14:12
  • But as I've said I've disabled *build automatically*. – Harold L. Brown Jul 16 '15 at 14:13
  • 1
    It has nothing to do with auto build. Any time you do something in eclipse, eclipse will track that work in his meta data. – Rene M. Jul 16 '15 at 14:14
  • If it's something you don't want to commit you could pull from HEAD to change it to the current HEAD revision. To do that right click the .project file -> `Replace with` -> `HEAD Revision` – DrZoo Jul 16 '15 at 14:14
  • Try a rebase on the other branche if there is nothing you won't to keep in the active branch like the ".project" file. – Rene M. Jul 16 '15 at 14:15
  • @ReneM. You were right: *build automatically* was enabled. Then I did _git clean_ to remove the files and now it works. – Harold L. Brown Jul 16 '15 at 14:15
  • Also make sure that you have `.project` and other Eclipse/IDE specific files in your `.gitignore`. – Markus Ratzer Jul 16 '15 at 14:17

2 Answers2

0

you should add this file to your ignore list it won't be affected by incoming commits. to do this you should have something like this in your .gitignore

target/
.settings
.classpath
.project
unique_ptr
  • 586
  • 1
  • 8
  • 22
  • It's a bad idea to have a `.project` and `.classpath` in the `.gitignore` list -- if you do a `git clean` or even a `git reset --hard HEAD` then you will blow these files away and your project will no longer work. – AlBlue Jul 17 '15 at 00:31
  • The idea about using shared repo is not to share your own specific settings unless you share this for yourself, if you work on a team then you have to keep your setting to your self. Have a look at eclipse projects hosted on github and you will learn a little bit about this. – unique_ptr Jul 17 '15 at 01:27
  • @Ridah I have been working with Eclipse for over a decade (in fact, since before it was called 'Eclipse', and I've written two books on the subject. I know what I'm talking about. The `.project`, `.settings` and `.classpath` are not per-user settings, they're project settings. – AlBlue Jul 27 '15 at 21:28
  • @AlBlue nice to hear that :) , I agree that `.project` and `.classpath` are project settings but `settings` isn't just for preferences storage ? beside in a complex project this would lead to a time wasting. Some don't want to have a builder configured ( mvn for ex ), the other don't have the same IDE version etc..., this might be an advantage for a team of 5 in the same building, but having code shared between France, India and USA, one should be really careful, I still believe that the safest is to keep these files in the ignore list so they won't be committed/overriden – unique_ptr Jul 27 '15 at 21:48
  • The `.settings` folder is explicitly for per-project preferences that is designed to be checked into source control, such that everyone uses the same settings. This includes things like e.g. the file encoding (e.g. `utf8`), whether auto-formatting should use spaces or tabs, whether `import *` should be rewritten and so on. The idea is that each project has this so everyone's operations are the same. Per-user settings are stored in the workspace's `.metadata` folder instead. – AlBlue Jul 28 '15 at 07:46
0

You should have the .project file (as well as other files like .settings and .classpath) under version control, so that when you do a git clean or a git reset --hard HEAD you don't blow them away.

The .project file has a few purposes:

  1. To store the name of the project
  2. To store the list of dependent projects
  3. To store the list of associated builders/natures

The file itself doesn't get updated regularly; only when you add a new nature or rename the project should it get cleaned. If you're using an old build tool then it might be re-writing the .project file to add dependent projects in place; but usually that doesn't happen.

Does a git diff show any changes on the file? It may be that there's a newline conversion issue, where git thinks that the file is different (because it has different EOLs) even though conceptually it's the same file.

You can also compare the content of the file against another branch using git diff HEAD..otherbranch -- .project to just show that file change.

Finally, are you doing the replace in Eclipse or in an external tool like TortoiseGit? If the latter, you might be confusing Eclipse and it may be better to let Eclipse's JGit integration do the change for you.

AlBlue
  • 23,254
  • 14
  • 71
  • 91