"Theodore Ts'o" <tytso@xxxxxxx> writes: > OK, here's my second attempt at a git-mergetool subcommand. > > Major differences from last time, besides addressing the comments made > by Junio, is that the git-mergetool now handles various scnearios where > the conflicts are caused by files changing to/from symlinks, and where > the symlink was changed to two different destinations in the local and > remote branches. Thanks. By the way, is it fashionable to misspell "scenario" in the kernel circles? ;-) > + git cat-file blob ":1:$path" > "$BASE" 2>/dev/null > + git cat-file blob ":2:$path" > "$LOCAL" 2>/dev/null > + git cat-file blob ":3:$path" > "$REMOTE" 2>/dev/null > + > + if test -z "$local_mode" -o -z "$remote_mode"; then > + echo "Deleted merge conflict for $path:" > + describe_file "$local_mode" "local" "$LOCAL" > + describe_file "$remote_mode" "remote" "$REMOTE" > + resolve_deleted_merge > + return > + fi Running cat-file even when you know it does not exist at that stage does not feel right here, although you are not checking the exit status and discarding 2>/dev/null... One situation that happens in the real life to cause "we deleted while they modified" is when in reality we moved then modified so much that the difference between our version and the common ancestor version is too large to be considered a rename anymore. Such a misidentified rename would appear as one path that is "we deleted while they modified" (original path) and the other path that is "we created while they didn't do anything to the path". The latter does not conflict and is already resolved in the index when you would run git-mergetool. So if you have "we deleted while they modified" conflict, it may make sense to give the paths the index adds (relative to HEAD), let the user pick one of them and allow 3-way merge to update the path we renamed to. The original path which had conflicted would be removed as the result. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html