[darcs-users] User interface for conflicts: confusing enough to lose data
droundy at abridgegame.org
Tue Jul 27 10:27:24 UTC 2004
On Mon, Jul 26, 2004 at 09:09:35PM -0400, Andrew Pimlott wrote:
> [Replying to old mail.]
> On Wed, Jun 30, 2004 at 06:51:48AM -0400, David Roundy wrote:
> > On the whole, I think we're better off with a separate command here. I
> > think what you'd really want is something I wasn't able to figure out
> > how to do, which is to have the contents of a repo with a conflict in
> > it include the marker. I definitely wanted to do this, and tried for
> > about a year to do so, but failed. The problem is that there's no way
> > that I was able to figure out to mark conflicts in a manner that will
> > be reproducible regardless of the order of merging.
> Why can't you use a simple alphabetical ordering of patch names? The
> concept strikes me as a win, because you want the tree to be
> conspicuously broken after a conflict.
That probably would work if the merge were done in such a way that I knew
what the patch names are (and is a good idea). But I currently do the
merge things recursively and don't carry that "patch name" information
around at the lower levels. To change this would definitely require
significant code rewriting--and thus be post-1.0 work.
> > I don't really remember what CVS-style markers look like, and when I
> > played with diff3 a bit, I couldn't get it to produce anything that
> > seemed familiar. You're welcome to submit a patch making this change,
> > hopefully extending it to the multi-way conflict in a consistent
> > manner, and I'll see how it looks. Since this is a pretty common
> > request, unless I really don't like it (for example, if there's no
> > consistent-looking way to extend it to a three-way conflict), I'll
> > probably accept it.
> If this is done, may I request the diff3 variant in which all three
> (potentially N+1, where N is the number of contributing patches) versions
> of the file are shown: with patch a, with patch b, and with neither? Two
> versions are really not enough to resolve a conflict. (Other formats
> with equivalent information would be interesting to consider. For
> example, the original plus the text of the N conflicting patches; or the
> N new versions plus the text of the N patches...
That does sound like a good idea. On the other hand, depending on how
things were done, one might be able to see the original version by running
a darcs whatsnew, which might in some ways be a "cleaner" way of looking at
More information about the darcs-users