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

David Roundy droundy at abridgegame.org
Mon Dec 6 12:55:09 UTC 2004


On Sun, Dec 05, 2004 at 07:01:46PM +0100, Norbert Nemec wrote:
> Am Sonntag, 5. Dezember 2004 13:45 schrieb David Roundy:
> > 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.

That would depend on the language and style of the code is being written
(and of the definition of "problem".  For example, I've worked on a fortran
program (alas) which had an index of input commands, so whenever you added
an input command you had to add an element to the index and increment the
size of the array.  When two people added two new commands, if identical
changes didn't cause a conflict, you could get a merge with no conflicts.

While it's not possible that darcs will see a conflict every time a merge
creates broken code, it's also not (always) correct to say that two
identical changes are the *same* change.

> 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.

Yes, now that I think about it, a separate "duplicate" patch type does seem
like a good idea.  While it's true that sometimes duplicates *are*
conflicts, since conflicts are always a pain, it is perhaps best to not
treat duplicates as conflicts.

> Commuting two identical patches is trivial: the "duplicate"-marker is
> simply swapped over to the other patch"

The trickier bit is commuting the duplicate patch with other patches.
There's also a question of what the inverse of a duplicate patch would be.
I think it would be a sort of "foreshadowing" patch, since it comes before
the patch it is duplicating.  The question is whether the foreshadow patch
is identical with the duplicate patch.  Which is to say, whether one can
make a symmetric duplicate patch, which doesn't know whether it is a
duplicate patch or a foreshadowing patch.


P* P <-> P* P

if foreshadowing patch is same as duplicate patch then:

(P* P)^-1 == P^-1 P^-1*

P^-1 P^-1* <-> P^-1 P^-1*

which means

P P* <-> P P*

which is a tad funky.

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

At some point we'll have to break backwards-compatibility and fossilize old
merges, and that's when this could be introduced, if it does work out and
seem like a good idea at that time.
-- 
David Roundy
http://www.darcs.net




More information about the darcs-users mailing list