5

Until now I merge simply with the fetch+merge approach and if there was a merge conflict I fixed it manually, staged it and commited. It resolved just fine.

Now I decided to try out the "synchronize workspace" thingie. I checkout my local branch and run that command on the remote branch of origin. How do I pull single files into my repository?

I tried using merge or pull, but instead of integrating the change, it suddenly tells me that there is a merge conflict. This conflict should not occur in the first place, but indexing and committing again does not fix the error. I synchronize with workspace and it keeps showing the two sided red error on two identical files...

David Trevor
  • 794
  • 1
  • 7
  • 22

2 Answers2

2

In my experience Synchronize Workspace confuses the most people.

In general it should be used "read-only". Don't try to resolve any conflicts here. Per default you are comparing your working copy against the remote repository. Which means you actually have no conflict in your working copy. When you "fix" them here you are just making a local modification. You can commit that but it doesn't resolve any conflict. It makes the actual conflict even harder to resolve.

I recommend not doing anything in the Team Synchronization perspective. Just do a pull (or fetch/merge) to have those conflicts in your working copy and then resolve them. You know how to do that. If something breaks and you want a new try do a reset --hard on the last commit in your local repository and start over.

Kai
  • 38,985
  • 14
  • 88
  • 103
1

Try instead a fetch + rebase: you will have to resolve the conflict again, but once that is done, your amended commit should be on top of origin/master: the next fetch should do nothing, since everything was fetched.

See this tutorial:

http://eclipsesource.com/blogs/wp-content/uploads/2012/09/Screen-Shot-2012-09-25-at-3.34.08-PM.png

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • How would that help? This would integrate all changes from origin – David Trevor Aug 16 '16 at 11:33
  • @taclight no: it would replay your local commits on top of origin/master. – VonC Aug 16 '16 at 11:35
  • @taclight " it keeps showing the two sided red error on two identical files..." by the way, are those identical files different in their name? (as in lowercase/upercase difference) – VonC Aug 16 '16 at 11:36
  • Which means on top of every single commit that has been made on master? How is that selective? And no, file names are identical. As I said, normal merge/rebase without the synchronize perspective runs fine. – David Trevor Aug 16 '16 at 11:41
  • @taclight no, it means your local commits made on master are replayed on top of origin/master (not master). The goal is to resolve the conflict locally, and the Synchronize view should not show any conflict after that: https://wiki.eclipse.org/EGit/User_Guide#Synchronize_View – VonC Aug 16 '16 at 11:48
  • Yeah the problem isn't that I can't push to master the problem is that after the selecting single files to merge I add them to the staging area to show Git the conflict is resolved. I then commit locally and run the synchronize with workspace again. It still shows me conflicts. The description of this symbol is `file has been changed in your workspace or local branch and in the target branch` but both files are identical. – David Trevor Aug 17 '16 at 07:31
  • @taclight Does that file still contain conflicts markers (`<<<<<`, `=====`, `>>>>`)? What `git status` says? (when the GUI is acting up, I always fall back to the CLI) – VonC Aug 17 '16 at 07:50
  • Nah, there wasn't a real merge conflict in the first place. Like no contradicting changes or anything. Lets say I select two out of three changes and merge them manually. The arrow shows, so I have to stage and commit locally to tell Git I merged these two files, no? What I expected was that in the synchronization view those two files disappear while one incoming change still shows. – David Trevor Aug 17 '16 at 08:02
  • Well just says it's one commit behind and one commit ahead, which makes sense regarding what I did – David Trevor Aug 17 '16 at 08:09
  • I guess it's not even possible in EGit to accomplish selective merging like in SVN... – David Trevor Aug 17 '16 at 12:06
  • @taclight indeed. Git is more commit-centric (you can cherry-pick: https://wiki.eclipse.org/EGit/User_Guide#Cherry_Picking) Or you use a .gitattributes (http://stackoverflow.com/a/8014154/6309), but Egit might ignore it (Git won't) – VonC Aug 17 '16 at 13:16
  • Thanks for your time. One last question about a scenario with the cherries... if I cherry pick just some of the commits over and over again, won't that completely mess up my history so I can't cleanly merge back to some branch or repository? – David Trevor Aug 17 '16 at 13:19