This bug report can be illustrated with the shell script uploaded through issue578.

The result is that after going through the Steve and Monica example from DarcsTwo, 
"darcs changes" reports that one conflicting patch contains no content at all!
That's definitely different than darcs-1, and looks like a bug to me. 

Example:
#####

$ darcs changes -s
Tue Jan  8 21:06:50 EST 2008  steve
  * Bnote

    M ./foo -1 +1

Tue Jan  8 21:06:49 EST 2008  steve
  * Anote


Tue Jan  8 21:06:50 EST 2008  monica
  * AZnote

    A ./bar
    A ./foo

I see.  This is because these are actually not conflicting changes,
but duplicate changes (which in darcs-2 are distinct).  I'm not sure
how best to summarize duplicate changes.

In one sense, the current behavior seems good:  this patch actually
has no effect, and file foo is only added once, so we only display
once that it's been added.

But on the other hand, it's also pretty useless:  we can't see what
change this patch represents!  :(

So it does seem that some summarization of duplicate changes would be
wise, but they aren't conflicts, so we don't want to mark them as
such, and I'm not sure how we *should* mark them.  :(  Ideas?

David

I see.  This is because these are actually not conflicting changes,
but duplicate changes (which in darcs-2 are distinct).  I'm not sure
how best to summarize duplicate changes.

In one sense, the current behavior seems good:  this patch actually
has no effect, and file foo is only added once, so we only display
once that it's been added.

But on the other hand, it's also pretty useless:  we can't see what
change this patch represents!  :(

So it does seem that some summarization of duplicate changes would be
wise, but they aren't conflicts, so we don't want to mark them as
such, and I'm not sure how we *should* mark them.  :(  Ideas?

David

David Roundy wrote:
> David Roundy <daveroundy@gmail.com> added the comment:
> 
> I see.  This is because these are actually not conflicting changes,
> but duplicate changes (which in darcs-2 are distinct).  I'm not sure
> how best to summarize duplicate changes.
> 
> In one sense, the current behavior seems good:  this patch actually
> has no effect, and file foo is only added once, so we only display
> once that it's been added.
> 
> But on the other hand, it's also pretty useless:  we can't see what
> change this patch represents!  :(
> 
> So it does seem that some summarization of duplicate changes would be
> wise, but they aren't conflicts, so we don't want to mark them as
> such, and I'm not sure how we *should* mark them.  :(  Ideas?

I think the change should reflect the effect of the patch in the absence 
of duplicates.

Showing the "dopple" as containing a change and the "ganger" as 
containing nothing is contextual. If the "dopple" patch as removed, then 
the "ganger" patch would start to reflect the change I suppose. (And 
this current behavior seems confusing).

I think it's fine if the effect of duplicate patches is duplicated in 
"changes". From a user's perspective, this seems "correct" because both 
patches did indeed contain a change, even if they cancel each other out.

<pauses>

What about another status letter, like "D" for duplicate, indicating 
that there is something different about the primitive patch? I'm not 
sure that's necessary, and could cause further confusion when part of a 
file contains a duplicate change, and part of it contains a "real" change.

   Mark

On Mon, Jan 14, 2008 at 09:49:42PM -0000, Mark Stosberg wrote:
> What about another status letter, like "D" for duplicate, indicating that
> there is something different about the primitive patch? I'm not sure
> that's necessary, and could cause further confusion when part of a file
> contains a duplicate change, and part of it contains a "real" change.

The trouble is that the duplicate patches may not be possible at the
current patch position in history.  e.g. if we have three changes

ab1: renames a to b
ab2: renames a to b
bc:  renames b to c

then if we have these three changes in the order ab1 bc ab2, then the
summary would look like

ab1: a -> b
bc:  b -> c
ab2: a -> b (duplicate)

The summary of ab2 seems like nonsense if you don't include the fact that
it's a duplicate, since there is no file named "a" to rename to "b".

I'm just not sure what would be the best approach here.  :(
-- 
David Roundy
Department of Physics
Oregon State University

David Roundy wrote:
> David Roundy <daveroundy@gmail.com> added the comment:
> 
> I see.  This is because these are actually not conflicting changes,
> but duplicate changes (which in darcs-2 are distinct).  I'm not sure
> how best to summarize duplicate changes.
> 
> In one sense, the current behavior seems good:  this patch actually
> has no effect, and file foo is only added once, so we only display
> once that it's been added.
> 
> But on the other hand, it's also pretty useless:  we can't see what
> change this patch represents!  :(
> 
> So it does seem that some summarization of duplicate changes would be
> wise, but they aren't conflicts, so we don't want to mark them as
> such, and I'm not sure how we *should* mark them.  :(  Ideas?

I think the change should reflect the effect of the patch in the absence 
of duplicates.

Showing the "dopple" as containing a change and the "ganger" as 
containing nothing is contextual. If the "dopple" patch as removed, then 
the "ganger" patch would start to reflect the change I suppose. (And 
this current behavior seems confusing).

I think it's fine if the effect of duplicate patches is duplicated in 
"changes". From a user's perspective, this seems "correct" because both 
patches did indeed contain a change, even if they cancel each other out.

<pauses>

What about another status letter, like "D" for duplicate, indicating 
that there is something different about the primitive patch? I'm not 
sure that's necessary, and could cause further confusion when part of a 
file contains a duplicate change, and part of it contains a "real" change.

   Mark

On Mon, Jan 14, 2008 at 09:49:42PM -0000, Mark Stosberg wrote:
> What about another status letter, like "D" for duplicate, indicating that
> there is something different about the primitive patch? I'm not sure
> that's necessary, and could cause further confusion when part of a file
> contains a duplicate change, and part of it contains a "real" change.

The trouble is that the duplicate patches may not be possible at the
current patch position in history.  e.g. if we have three changes

ab1: renames a to b
ab2: renames a to b
bc:  renames b to c

then if we have these three changes in the order ab1 bc ab2, then the
summary would look like

ab1: a -> b
bc:  b -> c
ab2: a -> b (duplicate)

The summary of ab2 seems like nonsense if you don't include the fact that
it's a duplicate, since there is no file named "a" to rename to "b".

I'm just not sure what would be the best approach here.  :(
-- 
David Roundy
Department of Physics
Oregon State University

> I'm just not sure what would be the best approach here.  :(

Could we just mark one as a duplicate, sort of like you did?

The edge case is when there are two primitives in a file, and one is a 
duplicate and the other isn't. It might need two entries in "changes":

  M ./foo -1 +1 (duplicate)
  M ./foo -1 +1

Or maybe that should be:

  M ./foo -1 +1 (some duplicate changes)

Using another letter or two like "M" for this purpose seems to be the 
most consistent.

We could also solicit darcs-users for comments.

  Mark

> I'm just not sure what would be the best approach here.  :(

Could we just mark one as a duplicate, sort of like you did?

The edge case is when there are two primitives in a file, and one is a 
duplicate and the other isn't. It might need two entries in "changes":

  M ./foo -1 +1 (duplicate)
  M ./foo -1 +1

Or maybe that should be:

  M ./foo -1 +1 (some duplicate changes)

Using another letter or two like "M" for this purpose seems to be the 
most consistent.

We could also solicit darcs-users for comments.

  Mark

On Mon, Jan 14, 2008 at 10:43:06PM -0000, Mark Stosberg wrote:
> > I'm just not sure what would be the best approach here.  :(
> 
> Could we just mark one as a duplicate, sort of like you did?

Yes, that would be possible.

> Using another letter or two like "M" for this purpose seems to be the 
> most consistent.

I'm not sure that a single letter would be very clear.  It depends how
precise we want to be, I suppose.  For replace patches, we output something
like

  M ./foo -1 +1 r 1

so we might do something like this

  M ./foo -1 +1 r 1 d 2

but this is getting pretty obscure-looking.

> We could also solicit darcs-users for comments.

Not a bad idea.  Would you like to do this?
-- 
David Roundy
Department of Physics
Oregon State University

On Mon, Jan 14, 2008 at 10:43:06PM -0000, Mark Stosberg wrote:
> > I'm just not sure what would be the best approach here.  :(
> 
> Could we just mark one as a duplicate, sort of like you did?

Yes, that would be possible.

> Using another letter or two like "M" for this purpose seems to be the 
> most consistent.

I'm not sure that a single letter would be very clear.  It depends how
precise we want to be, I suppose.  For replace patches, we output something
like

  M ./foo -1 +1 r 1

so we might do something like this

  M ./foo -1 +1 r 1 d 2

but this is getting pretty obscure-looking.

> We could also solicit darcs-users for comments.

Not a bad idea.  Would you like to do this?
-- 
David Roundy
Department of Physics
Oregon State University

The solution, that I prefer is one of Mark Stosberg.

Adding (duplicate) to the summary:

M ./foo -1 +1 (duplicate)

And when there is a mix of duplicates and not duplicated changes:

M ./foo -1 +1 (some duplicate changes)

How about adding xN to all occurences, where xN indicates that the change occurs
in N places?

Tue Jan  8 21:06:50 EST 2008  steve
  * Bnote

    M ./foo -1 +1

Tue Jan  8 21:06:49 EST 2008  steve
  * Anote

    A ./foo x2

Tue Jan  8 21:06:50 EST 2008  monica
  * AZnote

    A ./bar
    A ./foo x2

Sorry, I just realised that's this is pretty much what David proposed :-)

Eric Kow wrote:
> Eric Kow <eric.kow@gmail.com> added the comment:
> 
> How about adding xN to all occurences, where xN indicates that the change occurs
> in N places?
> 
> Tue Jan  8 21:06:50 EST 2008  steve
>   * Bnote
> 
>     M ./foo -1 +1
> 
> Tue Jan  8 21:06:49 EST 2008  steve
>   * Anote
> 
>     A ./foo x2
> 
> Tue Jan  8 21:06:50 EST 2008  monica
>   * AZnote
> 
>     A ./bar
>     A ./foo x2

I find this not as clear. I might need to crack open the manual to find 
out what "x2" means, while "(duplicate changes)" or the like is 
immediately clear.

However, you could argue that this is consistent with the single letter 
codes like "A" and "M" which may need to be looked up, although these 
will be familiar to users of other SCM systems, while a notation about 
duplicates will not be.

    Mark

Eric Kow wrote:
> Eric Kow <eric.kow@gmail.com> added the comment:
> 
> How about adding xN to all occurences, where xN indicates that the change occurs
> in N places?
> 
> Tue Jan  8 21:06:50 EST 2008  steve
>   * Bnote
> 
>     M ./foo -1 +1
> 
> Tue Jan  8 21:06:49 EST 2008  steve
>   * Anote
> 
>     A ./foo x2
> 
> Tue Jan  8 21:06:50 EST 2008  monica
>   * AZnote
> 
>     A ./bar
>     A ./foo x2

I find this not as clear. I might need to crack open the manual to find 
out what "x2" means, while "(duplicate changes)" or the like is 
immediately clear.

However, you could argue that this is consistent with the single letter 
codes like "A" and "M" which may need to be looked up, although these 
will be familiar to users of other SCM systems, while a notation about 
duplicates will not be.

    Mark

Resolved by

Thu Mar 20 13:02:55 EDT 2008  David Roundy <droundy@darcs.net>
  * resolve issue579: display duplicate changes in summary.
  The code here really could use a cleanup.  But this change fixes things so
  you can now see duplicate changes in changes -s.

although apparently the automatic trigger misfired...