In the following transcript, I expect the "darcs diff" at the end to  
show that the line added by patch "b2" was "WHAA", not "WHOO".

I just ran afoul of this issue in practice, and it took me a little  
while to realize that darcs was sending me on a wild goose chase when  
it told me (by the output of "darcs diff") that a certain patch had  
made a certain change, when in truth that change was made by a  
different patch with which this patch conflicts.

Oh wait -- just now in reviewing this bug report before sending it,  
I've realized that darcs diff says that patch b2 *subtracted* line  
"WHOO", not that it added line "WHOO".  This is better!  It is  
nonsensical and confusing, which is better than plausible but wrong.   
However, it would be even better if "darcs diff" said that patch "b2"  
simply added line "WHAA".

Regards,

Zooko

wonwin-mcbrootles-computer:~/darcsbug$ mkdir i
wonwin-mcbrootles-computer:~/darcsbug$ cd i
wonwin-mcbrootles-computer:~/darcsbug/i$ darcs init
wonwin-mcbrootles-computer:~/darcsbug/i$ cat > f
WHEE
wonwin-mcbrootles-computer:~/darcsbug/i$ darcs add f ; darcs record -- 
all --author=a -m"init f"
Finished recording patch 'init f'
wonwin-mcbrootles-computer:~/darcsbug/i$ cd ..
wonwin-mcbrootles-computer:~/darcsbug$ darcs get i b1
Copying patch 1 of 1... done.
Finished getting.
wonwin-mcbrootles-computer:~/darcsbug$ darcs get i b2
Copying patch 1 of 1... done.
Finished getting.
wonwin-mcbrootles-computer:~/darcsbug$ cd b1
wonwin-mcbrootles-computer:~/darcsbug/b1$ cat >> f
WHOO
wonwin-mcbrootles-computer:~/darcsbug/b1$ darcs record --all -- 
author=a -m"b1 f"
Finished recording patch 'b1 f'
wonwin-mcbrootles-computer:~/darcsbug/b1$ cd ../b2/
wonwin-mcbrootles-computer:~/darcsbug/b2$ cat >> f
WHAA
wonwin-mcbrootles-computer:~/darcsbug/b2$ darcs record --all -- 
author=a -m"b2 f"
Finished recording patch 'b2 f'
wonwin-mcbrootles-computer:~/darcsbug/b2$ cd ..
wonwin-mcbrootles-computer:~/darcsbug$ darcs get b1 m
Copying patch 2 of 2... done.
Finished getting.
wonwin-mcbrootles-computer:~/darcsbug$ cd m
wonwin-mcbrootles-computer:~/darcsbug/m$ time darcs pull -a ../b2
We have conflicts in the following files:
./f
Finished pulling and applying.

real    0m1.057s
user    0m0.010s
sys     0m0.030s
wonwin-mcbrootles-computer:~/darcsbug/m$ darcs diff -u -p"b2 f"
Thu Nov  1 09:37:36 MDT 2007  a
   * b2 f
diff -rN -u old-m/f new-m/f
--- old-m/f     2007-11-01 09:39:55.000000000 -0600
+++ new-m/f     2007-11-01 09:39:55.000000000 -0600
@@ -1,2 +1 @@
WHEE
-WHOO

wonwin-mcbrootles-computer:~/darcsbug/m$ darcs diff -u -p"b1 f"
Thu Nov  1 09:37:27 MDT 2007  a
   * b1 f
diff -rN -u old-m/f new-m/f
--- old-m/f     2007-11-01 09:40:06.000000000 -0600
+++ new-m/f     2007-11-01 09:40:06.000000000 -0600
@@ -1 +1,2 @@
WHEE
+WHOO

The trouble here is that the external diff program has absolutely no way to know
about conflicts.  I'm not sure what behavior you'd prefer.  In this case, the
net effect of patch b2 in its current repository position is to remove the WHOO
line by conflicting with it, and this is what diff tells you.  What would you
prefer?

In deferring this bug, in the absence of a suggestion for better behavior.

David

Hm, the darcs Diff command creates two repos that it runs diff
on, doesn't it. What if it marked conflicts in each of these
repos before running diff?

> Hm, the darcs Diff command creates two repos that it runs diff
> on, doesn't it. What if it marked conflicts in each of these
> repos before running diff?

Tommy,

Would the result be that the conflicts showed up as more differences between the
two repos, which the diff tool could then present to you...or what the conflicts
disappear because they were the same in both trees? 

I think I may like your suggestion, but I'm having trouble visualizing the effect. 

  Mark

On Sun, Jan 13, 2008 at 03:40:27PM -0000, Mark Stosberg wrote:
> Would the result be that the conflicts showed up as more differences between the
> two repos, which the diff tool could then present to you...or what the conflicts
> disappear because they were the same in both trees? 
> 
> I think I may like your suggestion, but I'm having trouble visualizing the effect. 

Well, the current situation is that darcs shows the diff from
the effect of the given patch to wherever, i.e., in case of a
conflict none of either the given patch's or the conflicting
patch's changes. My intention was to instead show the diff to
the "conflicted state" at the given patch, i.e., both the given
patch's and the conflicting patch's changes (surrounded by
conflict markup). But I didn't think of the horror it is to read
diffs of diffs. Now, darcs markup is different from the diff
formats, so it would maybe no be such a horror.

On Sun, Jan 13, 2008 at 04:39:40PM -0000, Tommy Pettersson wrote:
> Well, the current situation is that darcs shows the diff from
> the effect of the given patch to wherever, i.e., in case of a
> conflict none of either the given patch's or the conflicting
> patch's changes. My intention was to instead show the diff to
> the "conflicted state" at the given patch, i.e., both the given
> patch's and the conflicting patch's changes (surrounded by
> conflict markup). But I didn't think of the horror it is to read
> diffs of diffs. Now, darcs markup is different from the diff
> formats, so it would maybe no be such a horror.

Yes, this does seem like it's worth considering (as an option), and should
be *relatively* easy to implement.
-- 
David Roundy
Department of Physics
Oregon State University

On Sun, Jan 13, 2008 at 04:39:40PM -0000, Tommy Pettersson wrote:
> Well, the current situation is that darcs shows the diff from
> the effect of the given patch to wherever, i.e., in case of a
> conflict none of either the given patch's or the conflicting
> patch's changes. My intention was to instead show the diff to
> the "conflicted state" at the given patch, i.e., both the given
> patch's and the conflicting patch's changes (surrounded by
> conflict markup). But I didn't think of the horror it is to read
> diffs of diffs. Now, darcs markup is different from the diff
> formats, so it would maybe no be such a horror.

Yes, this does seem like it's worth considering (as an option), and should
be *relatively* easy to implement.
-- 
David Roundy
Department of Physics
Oregon State University