[darcs-users] two conflicting adds

[David Roundy]

On Tue, Apr 20, 2004 at 08:52:27AM +0100, Ganesh Sittampalam wrote:
> It seems that the merger of two adds does not create a conflict, but the
> second one just clobbers the first. This is rather inconvenient:
> 
> Patches B and C are created independently, each with context of Patch A
> and all before it. Each patch creates the same file and adds different
> contents to it. The semantically correct merger of B and C is for one of
> the added files to be renamed, so that both sets of content get added but
> with different names.

In darcs there is a distinction between the resolution (or marking) of a
conflict and the conflict itself.  What you are suggesting is certainly the
best resolution of the conflict.  For historical reasons, darcs is unable
to currently do that (because when it resolves the conflict, it doesn't
know what other files might exist, so it can't choose a new name).

> Intuitively, I'd have hoped to start in a repository with A, and pull B,
> then C, then get a conflict and be able to resolve the conflict
> appropriately - possibly by having the second add end up in a temporary
> file which I could rename and add?
> 
> This doesn't work because there is just no conflict at all.

That's not true, there *is* a conflict, it just isn't well "marked."  When
you ran the pull it told you that there was a conflict.  Of course, this is
still bad behavior, but it's not nearly as bad as it would be if there was
no conflict.

In general, the area of conflict resolution and marking needs work, and
this is a particularly bad case.

> In fact, the "obvious" workaround of pulling B, renaming the file, then
> pulling C doesn't work either because darcs helpfully commutes C with the
> rename and leaves exactly the same problem with the renamed file instead.

Yes, this doesn't work because if it did, you'd lose your history... or
rather your history gets messed up--since you have two files that at one
time had the same name, so patches from before the rename would be
ambiguous.  One could get around this by attaching a unique identifier
(e.g. the name of the patch which created it) to every file--but darcs
doesn't do this.

> Any thoughts, both about how I can actually do this merge in the
> short-term, and about the correct long-term fix?
>
> [Actually, the obvious short-term workaround for me is to unrecord B and
> redo it, since it's something I created, but it might have been something
> someone else pushed me]

Certainly in your current case, you should unrecord and rerecord, since
conflicts are always best avoided.

If that weren't a practical possibility (e.g. if both files had a number of
patches modifying them before the merge was done), you'd need to resolve
the conflict by adding both files (but not with the same name this time).
The information is all still there in your repo, and you'd probably want to
darcs get a copy of the repo, unpull one of the two sets of conflicting
patches, and then copy the file over by hand in order to get the other
version of the file.

In the slightly longer term, I've been thinking about creating an
interactive conflict resolution tool, which could be used to do this
without creating another copy of the repo.  In the somewhat-longer-term, a
smarter default resolution is definitely in order.
-- 
David Roundy
http://www.abridgegame.org