On Fri, Mar 16, 2012 at 15:04, Stefan Sperling <s...@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
