GNOME Bugzilla – Bug 756216
New git merging behavior (showing "BASE") triggered from dirdiff can be misleading about the state of partial merges
Last modified: 2017-12-13 19:14:05 UTC
As initially mentioned in bug 756148, the new functionality described at https://mail.gnome.org/archives/meld-list/2015-October/msg00004.html can be confusing if the merge is partially performed and the results saved. Specifically, in my case, I had resolved all of the conflict markers and saved the file to disk, but because the merge was not resolved by a "git add": - dirdiff still presented the file as having conflicts - when I reopened the file in meld from the dirdiff UI, the middle merge pane seemed to have been regenerated from scratch, ignoring the revised state I had already persisted to disk. (Making me think the save had failed.)
I'm struggling to figure out a good way of handling this case. Where I'm currently at is: * When we launch a comparison on a conflicted file, we check to see whether the MERGED file on disk has been modified * if so we display it; * if not we generate our merge-with-base file and display it. The trick here will be deciding whether the MERGED file has been modified. I can't think of a good way to do this at all. I think the options at this point are either: * Check the mtimes of LOCAL, MERGED and REMOTE files and if MERGED is more than some delta from the others, assume it's been modified; or * read MERGED and see whether it either doesn't contain any conflict markers, or only contains Meld's "==== BASE ====" conflict markers. Currently I'm inclined to go for the second of these, but I'd be very keen to hear any other suggestions.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/meld/issues/94.