On Fri, Mar 16, 2012 at 15:04, Stefan Sperling <stsp_at_elego.de> wrote:
>...
> 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.
This would be great. As you point out: very easy to resolve. It also
starts people on the path to recognize the inherent conflict and
acknowledging its resolution, even if that to typically accept the
suggestion.
If users provide feedback of "that's really annoying", then we can add
a knob :-(
Personally, I'd be surprised if an edit/move conflict is all that
common. Maybe you/others have some data on this? More prevalent in
larger teams? Remote uncoordinated teams?
> 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.
To clarify my understanding: this is only necessary if we choose the
above option? In "today's" code, it may flag a text conflict, so
adding the capability for a edit/move conflict is additional work?
> 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.
Sure. Again, two options to resolve a conflict, and we leave the tree
in the "typical resolution" state. The user could also resolve it to
remove their localmod and accept the deletion.
> 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 :)
I've never agreed with that. :-)
> 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.
Ugh. "theirs" and "mine" is really poor terminology, which is
especially evident as you attempt to contort them into some kind of
meaning above :-P ... I'd suggest that we have
--accept=token1,token2,token3 ... where the tokens describe which type
of resolution to perform. AFAIK, commas are not allowed in --accept,
so this would be forward-compatible. In your above scenario,
--mine-full is not "full" as it needs to switch your move into a copy,
and reinstall the (updated) move-source. That's why I don't like
trying to fudge resolutions into a limited set of names. We kind of
end up back in the --force fiasco :-)
Cheers,
-g
Received on 2012-03-16 21:08:21 CET