"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: got patch; got patch -R
To:
Omar Polo <op@omarpolo.com>
Cc:
Christian Weisgerber <naddy@mips.inka.de>, gameoftrees@openbsd.org
Date:
Thu, 21 Jul 2022 19:20:47 +0200

Download raw body.

Thread
On Thu, Jul 21, 2022 at 06:38:51PM +0200, Omar Polo wrote:
> i've updated the test, now it generates a conflict like this:
> 
> 	1
> 	2
> 	3
> 	4
> 	<<<<<<< --- numbers
> 	5
> 	6
> 	||||||| +++ numbers
> 	five
> 	=======
> 	five
> 	six
> 	>>>>>>> commit $commit_id

> which seems correct to me.  The diff was
> 
> 	 4
> 	-5
> 	+five
> 	 6
> 
> and the latest release of the file had s/5/five and s/6/six.

Playing around with merge(1), which is a thin wrapper around the
RCS merge machinery, I realize now that my explanation of how a
reverse-merge needs to be done wrong. I said the left/right versions
need to be swapped, but it actually works as follows:

In a regular merge, the "base" is the oldest version of the file,
and left and right are two derived, i.e. newer, versions.

Try this:

jot 10 > numbers
jot 10 | sed s/5/five/g > numbers-left
jot 10 | sed -e s/5/five/g -e s/6/six/g > numbers-left
merge -p numbers-left numbers numbers-right 

The above displays the forward-merge conflict. I arbitrarily chose -left
as the version on "our" branch of history; this content is displayed in
the first conflict section.

To do a reverse-merge, we must pick a base which represents the "newest"
version of the file, and use the oldest and other derived file as left
and right inputs.

According to the merge(1) man page, the first file argument represents
the merge target file, i.e. this should be the version of the file the
user wants to arrive at. And when backing out the change, the file we
want is the old "original" file, as it used to exist before the change
was applied:

merge -p numbers numbers-left numbers-right 

In this command, the second argument determines which context appears
as the merge base in the conflict marker, and the third argument
appears in the lower conflict section.

So what got patch needs to do is the equivalent of this:

regular patch: merge -p numbers-left numbers numbers-right 
[[[
1
2
3
4
<<<<<<< numbers-left
five
6
=======
five
six
>>>>>>> numbers-right
7
8
9
10
]]]

reverse patch: merge -p numbers numbers-left numbers-right 
[[[
1
2
3
4
<<<<<<< numbers
5
6
=======
five
six
>>>>>>> numbers-right
7
8
9
10
]]]

And this seems to be exactly what your proposed diff is doing, correct?