| Merge tool - better remove conflict markers functionality when rejecting change? [message #1262460] |
Mon, 03 March 2014 17:02  |
 john db
Messages: 2
Registered: May 2010 |
Junior Member |
|
|
I think it would be better if EGit merge tool had some way to reject an incoming change(s) and automatically remove any remaining conflict markers in a conflicted file without having to edit and save the conflicted lines.
Let me explain what I mean by example. These steps try to replicate the setup for a development team using EGit and having a central Repo to share changes.
Create an Eclipse Java project (outside workspace). Add a Java package and a Java Class inside the package. Put the project under Git Source control (Team\Share project..etc). We'll call this repo Dev1.
Clone the repo Dev1 and create a bare repo (to act a central shared repo). We'll call this CentralRepo.
Now switch to a second eclipse workspace, add CentralRepo in Git repository exploring. Clone the repo CentralRepo. We'll call the clone repo Dev2. This will act as a local repo for this second eclipse workspace). Import the project from Dev2 into the second eclipse workspace.
Edit a line in the Java class. Commit the change. And then push the change to CentralRepo.
Switch workspace back to the first workspace with the project from repo Dev1. Edit the same line in the same Java class. Commit and push to CentralRepo. The push is rejected. Do a pull. The merge raises the conflict.
EGit adds the conflict markers around the line in question. Select the file, select the merge tool (head revision). .
The merge tool uses the standard Eclipse compare files view. It has options to copy over the incoming change into the local file. However, and this is the problem, there is no option to reject the remote change and have the conflict markers automatically removed from the conflicted file.
When the conflicted line has been edited in any way in the compare files view and the file is saved, only then the conflict markers will be removed. So the minimum side-effect free change a developer can do to keep the local version of the line is to add a white space at the end of the line, then save the file and EGit will remove the conflict markers around the line. This is not a lot of work for one line. But what if there are files with many conflicts mixed in with some valid incoming changes. Each conflict line will have to have some edit even if you want to keep the local version unchanged.
You might argue that if there is a conflict then there is often a good reason for it and it is never the case that you can ignore the remote change. This may be true for like 75% of the time. But if you have junior developers pushing code or someone makes a mistake or changes their mind after some discussion, then these are still valid use cases when you want to easily reject the remote incoming change.
Eclipse CVS behaves better in this regard, when the file is marked as resolved then no conflict markers would remain in the files. The local version of the file is taken as perfect in its current state. Unlike with EGit, when you Mark as resolved or add to index, and you haven't edited the conflicted file then the conflict markers will remain in the file. At this point you would have to go into the file and manually remove conflict markers. There is no reason you would want to keep the conflict markers in the file or commit/push a file with conflict markers after you have marked as resolved/ added to index - the programs won't compile!
I work in a development team that is using Eclipse and the built-in CVS for their projects. We also use MS Windows and don't have much choice here. I was going to be recommending we migrate to using EGit instead of CVS, with one of the advantages being that it should do better, smarter and safer merging of branches. However I was disappointed to find this basic shortcoming in behavior compared to CVS, which will in some ways mean more work involved when merging. The developers on the team are used to working in Windows and I don't think they've ever seen conflict markers. As it seems to be of unix/linux origin. Of course, it's not that difficult to understand once it's been explained. But the point is that the ideal user-friendly tool should aspire to hiding these low level details from the user in daily use, and they never had to worry about it when working with CVS.
I tested this same workflow example with the MercurialEclipse plugin. And it works very smoothly and very easy to use. I would recommend our team use MercurialEclipse if it weren't for some other basic buggy behaviour with it that raised doubts about its long term reliability and support in contrast to EGit.
I think that this desired behaviour could easily be added for Egit to either the Mark as resolved or Add to index commands.
Not sure whether to post this here or the developer mailing list. But I'll try here first. Let me know if the dev mailing list would be more suitable.
Thanks
|
|
|
|
Powered by
FUDForum. Page generated in 0.02821 seconds
] 
Search
Help
Register
Login
Home
