GNOME Bugzilla – Bug 484177
Incorrect hunks appear at the end of the files in three-way mode
Last modified: 2009-09-01 01:33:56 UTC
Please describe the problem: As you work your way through a three-way merge top-to-bottom, sometimes the files go out-of-whack somehow, and a portion of the bottoms of the left and right, although they do not differ at all from each other or from the left pane, are all of a sudden being considered hunks that need to be merged into the central pane (usually one line apart). Please have a look at the screenshot for 1000 more words. Steps to reproduce: 1. Start merging (from monotone) 2. Keep an eye on the bottom of the three panes Actual results: You get these hunk artifacts that shouldn't be there ate all Expected results: If the files are identical, I do not expect meld to suggest that I append two more copies of a hunk to an existing, identical hunk in the middle file. Does this happen every time? No, but quite often, especially when lots of merges are necessary. Other information: One time, this has prevented me from merging a file, because a very large portion from the bottom was all of a sudden marked for inclusion into the middle, obscuring the actual hunks that needed merging. The workaround was to merge the file from the bottom up.
Created attachment 96774 [details] Illustration of the merge artifacts
meld version 1.1.5.1, according to Help -> About
Traceback (most recent call last):
+ Trace 168416
self._after_text_modified(buffer, starting_at, -self.deleted_lines_pending)
change_range = self.linediffer.change_sequence( pane, startline, sizechange, self._get_texts())
changes[1] = self._change_sequence( 1, sequence, startidx, sizechange, texts)
assert rangex[0] <= rangex[1] and range1[0] <= range1[1] AssertionError
That's what it says when I get that particularly large and fatal false hunk.
Can you attach three files on which you can reproduce the problem?
Created attachment 97154 [details] Left file
Created attachment 97155 [details] Middle file
Created attachment 97156 [details] Right file Instruction: Click such that all the hunks from the right go into the middle, except: 1. Remove the extra blank line from the middle (hilighted in green) 2. Leave the last chunk as it is. (My) result is that the last line of the left file (which is identical in all three) is offered for inclusion as the second-last line of the middle file (please see screenshot to follow shortly).
Created attachment 97157 [details] Illustration of the result of merging the 3 previous attachments This is a small and non-annoying example, but it may have the same cause as larger, more annoying examples. If I find better examples, I will attach them.
Created attachment 97172 [details] A more pronounced example. Left file.
Created attachment 97173 [details] A more pronounced example. Middle file.
Created attachment 97174 [details] A more pronounced example. Right file. Merging decisions I made, in order from top to bottom: right-to-center: 7 hunks middle:edit line 131: Remove whitespace right-to-center: 3 hunks middle:Remove lines [491,495] right-to-center: 1 hunk At this point, lines [3240,3272] in the left file are hilighted in green, and meld gives me the option to insert these lines between lines 3217 and 3218 in the middle file. In addtion, another weird thing: At this point, meld offers to take a hunk less than a line's thickness from between lines 3250 and 3251 in the middle file and insert it between lines 3242 and 3243 of the right file. I'm about to attach a screenshot.
Created attachment 97175 [details] Illustration of the result of merging the 3 previous attachments
More interesting stuff that happens when I try to click on those frivolous hunks: Traceback (most recent call last):
+ Trace 169999
self._after_text_modified(buffer, starting_at, lines_added)
assert rangex[0] <= rangex[1] and range1[0] <= range1[1] AssertionError Traceback (most recent call last):
assert self.deleted_lines_pending == -1 AssertionError Traceback (most recent call last):
changes[0] = self._change_sequence( 0, sequence, startidx, sizechange, texts)
I can confirm with 1.1.5.1-2ubuntu1 (intrepid amd64). This happens to me all the time. A quicker way to reproduce with the “more pronounced example” files is to delete 200 lines from the top of mid, then merge the next hunk from right to mid.
look at patch from bug http://bugzilla.gnome.org/show_bug.cgi?id=578303
I can't reproduce this from the instructions on the recent 1.3.1 release. As Vincent suggests, it looks like the fix from bug #578303 fixed this too. Closing - please reopen if you can reproduce with 1.3.1 or git head.