[darcs-users] User interface for conflicts: confusing enough to lose data

[David Roundy]

On Tue, Jun 29, 2004 at 08:56:52PM +0200, Juliusz Chroboczek wrote:
> >> In summary, just doing ``darcs pull; darcs revert'' will make
> >> conflicts impossible to note by any of the official tools in darcs.
> >> Once two conflicting patches are in a repository (as opposed to being
> >> in two repositories with a common ancestor), for all practical uses
> >> both are lost with no visible indication of the fact.
> 
> > It would probably be a good idea to add a "re-resolve conflicts"
> > command of some sort.  This wouldn't be too hard to code, but I'm not
> > sure what I'd call it.
> 
> Er... revert?  (You could include a revert --force flag, which
> preserves the curren behaviour.)

Would you also want to make whatsnew not display the conflict resolution? I
don't like the idea that revert followed by whatsnew gives anything bug "No
changes".  Or conversely the idea that whatsnew could display "No changes"
and yet revert actually does something makes no sense to me.  And if we
*did* make a change in whatsnew, then we'd have a weird situation where
whatsnew gives "No changes", but you can still record...

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.

> Additionally, I think that a record should fail if there are
> unresolved conflicts (unless, of course, it resolves a conflict), at
> least in the case where the conflict is already at the top of the
> stack.  Of course, there should be a record --force.

Hmmmm.  It would be hard to see if a record would resolve a conflict, and
I'm not sure that a record *should* fail just because there are conflicts.
What if I've made a change to a single file, then I pull your changes and
they conflict with some changes I made previously, but don't touch the
single change in a single file.  Why shouldn't I be able to record my
change before dealing with the conflicts? Or rather, why should this be
considered a "forcing" behavior? It seems perfectly natural to me...

> >> [1] Minor nit: could the markers please be standard diff3 style?  It
> >> might not be the best style around, but it's what we're used to 
> >> working with.
> 
> DR> I'm not sure what diff3 style looks like but the trouble with marking
> DR> conflicts in darcs is that it's possible to have an N-way conflict, so
> DR> CVS-style marking isn't sufficiently general.
> 
> CVS uses diff3-style markers.
> 
> Would it be okay if I made the marker format compatible with diff3 in
> the common case of two-way conflicts?  Both I and Emacs already know
> how to work with them.  (On the other hand, interfacing Emacs Lisp
> with Haskell is one of the exciting things in life.)

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.

> P.S. Unreleated non-urgent feature request.
> 
>   darcs switch [repo1] repo2
> 
> unpulls all the patches that are in repo1 but not in repo2, pulls all
> the patches that are in repo2 but not in repo1, and sets lastrepo to
> repo2.  repo1 defaults to lastrepo.

Hmmm.  I can see how this could be useful.  It eliminates the danger of
data loss due to unpull (since we know the patch is in repo1), and allows
you to quickly switch which "version" you're looking at.  The only problem
is that it took me a minute or so to see both what it does and why one
would want to do it, and I'm still not sure exactly when I'd want to use
it.

The difference between switch and get is that unrecorded changes get
propogated over, and recorded changes not in repo1 get propogated over, and
of course you retain your working directory state--the object files etc,
which may not be a trivial consideration.

I guess you might use this if you want to test a bugfix in two branches
before recording?
-- 
David Roundy
http://www.abridgegame.org