[darcs-users] why do identical changes have to be conflicts?

[Norbert Nemec]

Am Sonntag, 5. Dezember 2004 13:45 schrieb David Roundy:
> On Sun, Dec 05, 2004 at 03:08:44AM +0000, Mark Stosberg wrote:
> > I just confirmed in two scratch repos that darcs considers identical
> > changes made in different patches in two repos to be conflicts.
> >
> > What would it take for darcs to be smarter here, since it's 'obvious'
> > that there is not really a conflict, and using either identical line
> > will work just as well?
> >
> > It seems like if this test could be made earlier than later, it could
> > increase performance and resolution of the kind of conflict that happens
> > when two darcs users both cleanly apply the same patch from outside
> > darcs.
>
> The trouble is that the two patches might *not* be identical in intent.
> This change would mean that when two files of the same name are created by
> separate patches, they'd be treated as the same file, which would be wrong
> as often as it'd be right.  More to the point, it would most likely lead to
> inconsistencies.

This is true for adding files only. For hunk patches, there should not be any 
problem.

Furthermore: even for adding files, I don't see the problem. If you don't add 
any content, there is no conflict. If both patches add the same content, 
there is no conflict either - obviously, both wanted to create the same file. 
If both add different content, you get the regular conflict of the content.

> > It would still be a benefit if this check was only made 'at the last
> > minute'-- It could safe confusion of looking sets of conflict markers.
>
> Well, we used to be "smart" about identical changes when resolving
> conflicts, but then that confused people, because they'd see that there is
> a conflict, but wouldn't see any markers!

That is only true if you call it "conflict" in the first place. Perhaps the 
solution would be in the other direction: if two identical hunk patches are 
encountered, give a note that the second one is ignored as duplicate but 
don't count it as conflict.

In the patch-registry, such duplicates should certainly be kept just the same, 
so that you can later still commute the patches without ill effect.

Maybe this idea would ask for an extension of the theory of patches by the 
concept of "identical patches"? Something like:

 "Two identical patches do not conflict. Merging two identical patches P_1 and 
P_2 results in the second one being marked as duplicate (P*):
  P_1 || P_2 => P_1* P_2 <--> P_2* P_1
 Commuting two identical patches is trivial: the "duplicate"-marker is simply 
swapped over to the other patch"

Don't ask me about backwards-compatibility and stability, though... :-)

Ciao,
Nobbi

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <Norbert at Nemec-online.de>