On Fri, Sep 30, 2016 at 07:09:15PM +0300, Evgeny Kotkov wrote: > Hi, > > I was thinking about which options should be offered by the tree conflict > resolver in a common case with a catch-up merge when a file is moved > away in trunk and edited on the branch. (Limiting the scope to a case > when we can detect the move.) > > Currently, the resolver offers the "move local file and merge" option, but > also offers to ignore or accept the incoming deletion: > [[[ > > File merged from > '^/serf/trunk/serf.h@33' > to > '^/serf/trunk/serf.h@36' > was moved to '^/serf/trunk/serf_deprecated.h' by evgeny.kotkov in r35. > A file which differs from the corresponding file on the merge source branch > was found in the working copy. > > (p) - skip this conflict and leave it unresolved [postpone] > (r) - accept current working copy state [working] > (i) - ignore the deletion of '^/serf/trunk/serf.h@36' > (a) - accept the deletion of 'serf.h' > (m) - move 'serf.h' to 'serf_deprecated.h' and merge > (h) - show this help (also '?') > (q) - postpone all remaining conflicts > > Select: (p) postpone, (r) accept current working copy state, > (i) ignore incoming deletion, (a) accept incoming deletion, > (m) move 'serf.h' to 'serf_deprecated.h' and merge, > (h) help, (q) quit resolution: > > ]]] > > The resolver says that it has detected a move, so options "(i) ignore > incoming deletion" and "(a) accept incoming deletion" can confuse the > users (what's deleted?). And, if we know that it's actually a move, I > cannot think of a case where ignoring or accepting the deletion would > prove useful. > > Perhaps, for cases when we know that a move happened, it would be better > to just say: > > Select: (p) postpone, (r) accept current working copy state, > (m) move 'serf.h' to 'serf_deprecated.h' and merge, > (h) help, (q) quit resolution: > > I could implement this behavior. How does it sound? > > > Regards, > Evgeny Kotkov
I'd say yes, let's try that. The delete options are there now because I added them before adding a move+merge option became possible. One concern is that perhaps the move heuristic gets it wrong, and there was in fact a deletion. But if that happens we should fix the problem where it really is: in the move detection algorithm. Thanks!
