Conflicts when editing last line in ancestor

[jacg]

In a repository like this

jj git init /tmp/what
cd /tmp/what
echo won >  the-file ; jj commit -m "Add line 1"
echo too >> the-file ; jj commit -m "Add line 2"
echo tri >> the-file ; jj desc   -m "Add line 3"
jj edit @-

a conflict is created by

sed -i '2s/.*/two/' the-file

but not by

sed -i '1s/.*/one/' the-file

The conflict looks like this:

won
<<<<<<< Conflict 1 of 1
+++++++ Contents of side #1
two
%%%%%%% Changes from base to side #2
 too
+tri
>>>>>>> Conflict 1 of 1 ends

Similarly, editing the only (and therefore also last) line in the previous change, gives a similar conflict. I've tried many experiments which are all consistent with what I observe here.

It appears that editing the last line leads to conflicts. If there were an inconsistency in the presence/absence of a newilne at the end of the last line, this would make sense, but AFAICT the newline at the end is there throughout.

The line is fully replaced in the edited change, it is not modified by the following change but the conflict marker suggests the contrary, so what is the source of the conflict?

[martinvonz]

After you change the second commit from "won too" (pretend that spaces are newlines) to "won two", we rebase the third commit on top. That means rebasing the "won too" -> "won too tri" change on top of "won two", which means we have a 3-way merge with "won too" as base and "won two" and "won too tri" as sides. We then line inputs up and see that they all start with "won " but have a conflict right after that because the base is "too" and the sides are "two" and "too tri".

The line is fully replaced in the edited change, it is not modified by the following change but the conflict marker suggests the contrary, so what is the source of the conflict?

The leading space in the " too" line in the conflict marker indicates that it's unchanged compared to the base.

[jacg]

I realize now that using homophones in my example was an mistake, I should have used something like

jj git init /tmp/what
cd /tmp/what
echo 1 >  the-file ; jj commit -m "Add line 1"
echo 2 >> the-file ; jj commit -m "Add line 2"
echo 3 >> the-file ; jj desc   -m "Add line 3"
jj edit @-
sed -i '2s/.*/b/' the-file

instead.

Reworded in terms of this version of the example, your answer becomes

After you change the second commit from "12" (pretend each character is on a separate line) to "1b", we rebase the third commit on top. That means rebasing the "12" -> "123" change on top of "1b", which means we have a 3-way merge with "12" as base and "1b" and "123" as sides.

Summarizing this visually gives us

123
12 -> 1b
1

Continuing with the adaptation of your answer to the modified example

We then line inputs up and see that they all start with "1" but have a conflict right after that because the base is "2" and the sides are "b" and "23".

giving the visual summary

123   side 2
1b    side 1
12    base

However, if we replace the edit of the middle commit, changing it from

sed -i '2s/.*/b/' the-file

to

sed -i '1s/.*/a/' the-file

then the conflict disappears.

In this case the visual summaries are

123
12 -> a2
1

and lining up the three relevant commits gives

123   side 2
a2    side 1
12    base

.

I'm failing to understand why there is a conflict in the example summarized on the left, but not in the one on the right:

conflict         no conflict
  123     side 2    123
  1b      side 1    a2 
  12      base      12 

bearing in mind that each of the 123ab characters in these summaries is on a separate line in the file being tracked.

Recalling your explanation (translated to the revised example):

We then line inputs up and see that they all start with "1" but have a conflict right after that because the base is "2" and the sides are "b" and "23".

and comparing it to the equivalent for the column on the right:

We then line inputs up and see that they all agree on "2" but have a conflict around it because the base is "1_" and the sides are "2_" and "1_3" ^{_{(where "_" is a marker for the "2" on which they all agree}}).

This gives rise to a slightly modified version of the previous summary table.

conflict         no conflict
  _23     side 2    1_3
  _b      side 1    a_ 
  _2      base      1_ 

Apologies for the long-windedness: I'm trying to clarify things as much as possible in my head. But I can't put my finger on exactly why the left column is conflicted, while the right one is not.

• Is it becasue of the contiguity of the changes on the left, but not on the right?
• Is it because on the left we edit a line which was introduced by the commit being edited, while on the line we are editing a line which was introduced by an earlier commit?

If it is the latter, then there is probably not enough information in the last table, and we need to look at something like this:

conflict   no conflict
123        123
12 -> 1b   12 -> a2
1          1

[bnjmnt4n]

This is explained by the 3-way merge algorithm.

The conflicted section in the first case has both sides and the base all with different content, hence there is a conflict.

For the non-conflicted version, the first conflicting line has both sides with the same content, hence that content is preserved as the output. The next conflicting line is empty in side 1 and the base, hence the newly added line in side 2 is chosen as the output. Hence, all the conflicting lines can be resolved and the second case ends up as non-conflicting.

[jacg]

Very briefly, summarizing your linked '3-way merge algorithm', there should only be a conflict if all three versions disagree:

1. Three different versions: conflict
2. Sides agree: use that
3. Base agrees with a side: use the other side

Here is the summary of the two situations, for easy reference:

conflict         no conflict
  _23     side 2    1_3
  _b      side 1    a_ 
  _2      base      1_ 

(Have I made a mistake in construting this this?)

The conflicted section in the first case has both sides and the base all with different content, hence there is a conflict.

Looking at the left (conflict) column in the summary, I see that base and side 1 agree that the line 3 is empty, therefore the other side, side 2, should be used, and an extra line with the content 3 should be added.

For the non-conflicted version, the first conflicting line has both sides with the same content [...]

Looking at the right (no conflict) column in the summary, I see that base and side 2 agree that line one contains 1, so we should use side 1's version: a. I don't understand how the quoted line can be true.

The next conflicting line [line 3] is empty in side 1 and the base, hence the newly added line in side 2 is chosen as the output

I agree. How does this differ from the conflicting case? (This is the whole point of my original question!)

Is it because the content of the second line is taken as context? In that case we get

         /-----conflict-----\         /-----no-conflict-----\
         context   no-context          context   no-context
side 2     23      3                     23      3    
side 1     b       empty line            2       empty line
base       2       empty line            2       empty line

in which case I do see three different versions in 'context conflict' and only two different versions in 'context no-conflict'.

[jacg]

I think I get it: in the conflict case, it's not that line 2 and (the originally non-existent) line 3 are being modified independently, rather the modification is a single hunk/unit.

In the non-conflict case, the presence of an unmodified line 2 between them, prevents the modification of line 1 and the (originally non-existent) line 3 from being considered a single unit.

When treated independently, there is no conflict; when treated as a single unit, there is a conflict.

Is that it?