On Fri, Mar 16, 2012 at 02:26:09PM -0400, Greg Stein wrote:
> On Fri, Mar 16, 2012 at 12:51, Stefan Sperling <stsp_at_elego.de> wrote:
> >...
> > case which we can already make today. And I've already implemented it
> > so what you're suggesting either amounts to additional work in the
> > current conflict resolver (ugh, I've tried that on the moves-scan-log
> > branch, and it sucks), or reverting what I've already implemented.
> >
> > I think we agree on what the end goal is. We just don't seem to agree
> > on temporary measures to ease some of the pain with conflicts that
> > users suffer today until we reach that end goal.
>
> Ah... now this is a fair point. Moving away from theory to pragmatism.
> It sounded like you didn't like the theory; but maybe you were just
> more concerned about "what we have now" ??
Yes.
> I think this leads to leaving the code as-is, or yanking it in favor
> of some kind of notification/conflict.
Middle-ground suggestion:
We perform the automatic merge *and* flag an "incoming edit vs. local move"
tree conflict. This alerts the user but makes it easy to fix the conflict
in the case where the incoming edit should be kept -- just mark as resolved.
Because the auto-merge can cause text conflicts we'd need to add support
for flagging both a tree conflict and a text conflict on the same node.
Which AFAIK is not supported at the moment.
The approach is similar to what we already do for "incoming delete vs.
local edit". In that case, we make the conflict victim appear as a copy
of the pre-update state, so that the user can just mark the conflict
resolved if the local edit is preferred over the incoming delete.
But I always thought everyone agreed that applying an incoming text
change to a locally moved-away file was the only reasonable resolution
option, based on my reasoning about the semantics of moves. Hence I was
surprised that you even raised this :)
Overall, I'd still prefer to keep this as it is.
> The former is "no more work",
> but does it paint us into any sort of corner to do this Right later?
In some future release, the default behaviour will be prompting.
We could make the auto-merge behaviour available without prompting
if the user passes --accept=mine-conflict, meaning "keep my rename
but apply incoming edits to it". And --accept=mine-full could map
to "keep my rename and do not apply incoming edits to it".
In turn, the --accept=theirs-* options would undo the local rename,
the idea being that the resulting state should match "their" version
as closely as possible.
Received on 2012-03-16 20:05:11 CET