Community
Participate
Working Groups
Steps to reproduce: * Set in preferences "Team->Git", "Merge Tool content" = "Last HEAD (unmerged)" * Produce a conflict * Open merge tool (double click the conflicting file in staging view) * Resolve conflict, save * Double-click the file again in staging view (still in unstaged viewer) Expected: merge tool uses modified working tree version of the file as "ours" input. Actual: merge tool still uses stage 2 as input; doesn't show modifications made. Not sure this can even be fixed reasonably. It would mean EGit would have to detect that the working tree file has been changed from the auto-merge version. The auto-merge version is not in the index. Work-around: stage/unstage the file.
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/179460
While this Gerrit change does solve this particular problem, it got me thinking... Why does EGit even _have_ the two options for the merge editor input at all? Neither "Last HEAD (unmerged)" nor "Workspace (pre-merged by git)" is the correct input for the Eclipse merge editor. The 'ours' version doesn't have all the merges that git already did, so the user has to copy all non-conflicting changes himself again. The pre-merged workspace version has the git conflict markers, which makes conflict resolution in the merge editor more tedious than necessary. The correct input for text files would be the workspace version as pre-merged by git, with all conflicts resolved to the 'ours' hunks. (I.e., what "git merge -X ours" would produce.) If that was the merge editor input, we wouldn't need either option. This version could be produced by EGit either * by running a "merge -X ours" via JGit once https://git.eclipse.org/r/c/jgit/jgit/+/179234 was in, or * by processing the pre-merged working tree file, removing any "<<<<" marker and removing anything from "=====" to ">>>>>", including those markers. The first approach might produce something else than C git's merge -X ours if the original merge was done via C git using other options (for instance, whitespace options). The second approach would need to account for custom conflict markers. (The working tree file might have been produced by C git.) @Matthias, what do you think?
(In reply to Thomas Wolf from comment #2) > * by processing the pre-merged working tree file, removing any "<<<<" marker > and > removing anything from "=====" to ">>>>>", including those markers. [...] > @Matthias, what do you think? A nice side-effect of this is that it will avoid problems with parsers falling over on invalid syntax (the git conflict markers) since these markers will simply no longer be in the input, so chances are much higher that the input is syntactically valid.
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/179460 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=1a26ef89e18a6697771cea36a6e2d084a1f783e7
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/181259
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/181259 was merged to [stable-5.12]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=889a158edf7c5260abf2a0a6b0b656949555e917
