[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jgit-dev] "instable" diff algorithms lead to wrong merge results
|
Hi,
sorry, I forgot to CC the mailing list on my last reply. I'll forward
the text of that mail and of Robins reply here. Robin, I hope thats
ok.
On Fri, Nov 5, 2010 at 19:04, Robin Rosenberg
<robin.rosenberg@xxxxxxxxxx> wrote:
>
> 5 nov 2010 kl. 17:47 skrev Christian Halstrick:
>
>> Hi,
>>
>>> I think you are. You cannot resolve the merge without conflict. In the case b there is a conflict,
>>> but since both sides does the exact same edit, the conflict can be easily and reliably be resolved automatically anyway. In a) there is
>>> an overlap between the inserted regions from ours and theirs at line 103 [the one with x()]. This assumes the merges
>>> has identified the lines 103-105 as the lines to grab from THEIRS.
>>
>> I don't get that. In my example there are no two case. I have one
>> merge operation. The merge will diff BASE and OURS returning an edit
>> Edit(101,101,101,103). The merge will also diff BASE and THEIRS and
>> this leads to an Edit(103,103,103,105). Consequently the merge
>> algorithm says: that's not a conflict. One side adds some lines
>> between 100 and 101 of the original text. And the other side adds some
>> lines between 102 and 103 of the original text. That are two
>> independent insertions in different, non-adjacent areas of the
>> original text. Why a conflict?
>>
>> Ciao
>> Chris
>
>
> 5 nov 2010 kl. 17:47 skrev Christian Halstrick:
>
>> Hi,
>>
>>> I think you are. You cannot resolve the merge without conflict. In the case b there is a conflict,
>>> but since both sides does the exact same edit, the conflict can be easily and reliably be resolved automatically anyway. In a) there is
>>> an overlap between the inserted regions from ours and theirs at line 103 [the one with x()]. This assumes the merges
>>> has identified the lines 103-105 as the lines to grab from THEIRS.
>>
>> I don't get that. In my example there are no two case. I have one
>> merge operation. The merge will diff BASE and OURS returning an edit
>> Edit(101,101,101,103). The merge will also diff BASE and THEIRS and
>> this leads to an Edit(103,103,103,105). Consequently the merge
>> algorithm says: that's not a conflict. One side adds some lines
>> between 100 and 101 of the original text. And the other side adds some
>> lines between 102 and 103 of the original text. That are two
>> independent insertions in different, non-adjacent areas of the
>> original text. Why a conflict?
>
> First, the three versions to use:
>
> BASE:
> 98: z1
> 99: z2
> 100: a() {
> 101: }
> 102:
> 103: b() {
> 104: }
>
> OURS:
> 98: z1
> 99: z2
> 100: a() {
> 101: }
> 102:
> 103: x() {
> 104: }
> 105:
> 103: b() {
> 104: }
>
> THEIRS:
> 98: x1
> 99: x2
> 100: a() {
> 101: }
> 102:
> 103: x() {
> 104: }
> 105:
> 106: b() {
> 107: }
>
> Diff BASE OURS, "strange" diff (L)
> insert lines 101-103 of OURS between 100 and 101 of BASE
>
> 101: }
> 102:
> 103: x() {
>
>
> Diff BASE THEIRS, plain diff (R)
> insert lines 103-105 of THEIRS between 102 and 103 of BASE
>
> 103: x() {
> 104: }
> 105:
>
> Then apply. Pick OURS, simple to apply onto BASE. However that alters the
> position where R should go next. Line 100 of BASE is still 100 since we insert
> after it, but we insert before 101, which is now 104. Next insert lines 103-105 of THEIRS
> between lines 101 and 104 of the result. That's just silly => conflict.
>
> line line'
> 98: 98: z1
> 99: 99: z2
> 100: 100: a() {
> insert R here? or...
> 101: }
> 102:
> 103: x() {
> insert R here?
> 101: 104: }
> 102: 105:
> 103: 106: b() {
> 104: 107: }
>
> -- robin
