Here's a patch to add the old text to conflict marking,
as discussed on the mailing list.

I didn't write any tests for this. In my defence, I didn't
break any either. Neither of these things is really ideal!

1 patch for repository http://darcs.net/screened:

Wed Sep  8 06:46:09 BST 2010  Ganesh Sittampalam <ganesh@earth.li>
  * include old text in conflict marks

Attachments

• include-old-text-in-conflict-marks.dpatch
• unnamed

On Mon, Sep 20, 2010 at 20:25:25 +0000, Ganesh Sittampalam wrote:
> Here's a patch to add the old text to conflict marking,
> as discussed on the mailing list.

How does this behave when you have nested or other fancy conflicts?

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
For a faster response, try +44 (0)1273 64 2905 or
xmpp:kowey@jabber.fr (Jabber or Google Talk only)

On Tue, 21 Sep 2010, Eric Kow wrote:

> On Mon, Sep 20, 2010 at 20:25:25 +0000, Ganesh Sittampalam wrote:
>> Here's a patch to add the old text to conflict marking,
>> as discussed on the mailing list.
>
> How does this behave when you have nested or other fancy conflicts?

There are two cases here:

(1) Nested conflicts where all the conflicting changes are recorded. Then 
you previously just got one set of conflict markers, often with more than 
two "result" choices. That continues to be the case; this patch just adds 
the "old" version at the top like with the simple case.

(2) A conflict where there were already unrecorded conflict markers. Here 
you previously ended up with nested sets of conflict markers that were 
typically completely unusable. I imagine that's still the case, though now 
that the old text is an explicit part of the conflict markers, and the 
unrecorded change is precisely against the old text, it might make for 
more predictable results. Still likely to be useless though!

I don't have any specific experience of (2), I could test it out if you 
think it's important.

Ganesh

On Tue, Sep 21, 2010 at 20:48:22 +0100, Ganesh Sittampalam wrote:
> I don't have any specific experience of (2), I could test it out if
> you think it's important.

I don't think this should block patch application, but it could be
useful to have conflict-generation and marking scripts, not necessarily
for automated regression testing (which is tricky because we're not
so much worried about "correct" output as "desirable" output and the
latter is harder to pin down because we don't necessarily know what the
right thing to want is).  But such a thing could be useful for Eyeball
Testing.


-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
For a faster response, try +44 (0)1273 64 2905 or
xmpp:kowey@jabber.fr (Jabber or Google Talk only)

On Wed, 22 Sep 2010, Eric Kow wrote:

> On Tue, Sep 21, 2010 at 20:48:22 +0100, Ganesh Sittampalam wrote:
>> I don't have any specific experience of (2), I could test it out if
>> you think it's important.
>
> I don't think this should block patch application, but it could be
> useful to have conflict-generation and marking scripts, not necessarily
> for automated regression testing (which is tricky because we're not
> so much worried about "correct" output as "desirable" output and the
> latter is harder to pin down because we don't necessarily know what the
> right thing to want is).  But such a thing could be useful for Eyeball
> Testing.

Agreed. Probably makes sense to make regression tests with clear labels 
that it's ok to update them if you really are improving conflict marking - 
just to guard against inadvertent modification.

Ganesh

This patch bundle (with 1 patches) was just applied to the repository http://darcs.net/.
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__darcs.net_.html#bundle-948a9b9fe2af135bd7b0145f000758668c717e3a

This patch bundle (with 1 patches) was just applied to the repository http://darcs.net/reviewed.
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__darcs.net_reviewed.html#bundle-948a9b9fe2af135bd7b0145f000758668c717e3a