Re: Diftool problems

From: Marcin Zalewski <marcin.zalewski@gmail.com>
Date: Apr 29, 2009, 19:55 UTC
Message-ID: <7c0fdf4f0904291255i4076df8cubb26fdb2d51826d4@mail.gmail.com>
In-Reply-To: <200904292142.59471.markus.heidelberg@web.de>

> The real fix would be to adjust the ediff snippet for difftool support.

The emas snippet was meant to work with mergetool and it does (I think). Changing the emacs code could indeed help with difftool but it would break mergetool.

> As you said yourself, git-difftool is not meant for merging files, so
> there is no reason to open more than 2 files at all.

I agree, but the current implementation of difftool uses mergetool library. That may be the reason why difftool is trying to come up with the third file. Here is the snippet of code from mergetool library that executes emerge in case of non-merge-mode:

"$merge_tool_path" -f emerge-files-command \
				"$LOCAL" "$REMOTE" "$(basename "$MERGED")"

> The built-in difftools 'emerge' and 'ecmerge' still seem to open LOCAL,
> REMOTE and MERGED. This should be fixed, so that they don't open MERGED
> any more, but I don't have emacs installed, so I shouldn't try it
> myself.

Again, I agree. This could be one of the possible solutions, but it would require that mergetool library is changed or rewriting pieces of mergetool in difftool. Correct me if I am wrong.

> Oh, and LOCAL shouldn't be copied to a temporary file in the first
> place, because people don't use git-difftool in read-only mode only.

I think that merge result could be a temporary file, like in mergetool. In a situation where I use git to track an SVN repository, difftool can be actually used to merge my uncommitted changes with a commit from someone else after doing svn rebase. On the other hand, I am no git expert so there may be a better way to handle this case.

-m