From: Markus Heidelberg <markus.heidelberg@web•de>
To: Marcin Zalewski <marcin.zalewski@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: Diftool problems
Date: Wed, 29 Apr 2009 22:48:05 +0200 [thread overview]
Message-ID: <200904292248.06107.markus.heidelberg@web.de> (raw)
In-Reply-To: <7c0fdf4f0904291255i4076df8cubb26fdb2d51826d4@mail.gmail.com>
Marcin Zalewski, 29.04.2009:
> > 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.
I'm sure the emacs snippet can be adjusted to work with both. If it is
called with 2 files, then it's for difftool, else for 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.
The file is called git-mergetool--lib, but more exactly it should be
called git-mergetool-difftool--lib, but who wants this? Difftool was
originally based on mergetool, but the recent refactoring introduced the
lib, which is shared by both, without belonging to one of them more than
to the other.
> That may be the reason why difftool is trying to come up with
> the third file.
Difftool isn't forcing a third file on you.
> 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")"
As said, this command shouldn't open the 3rd MERGED file, this should be
fixed. This part of the lib is not responsible for difftool.
> > 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,
No, that doesn't solve your problem with ediff.
Or do you set merge.tool=emerge and ediff is called due to the snippet
in your ~/.emacs? If yes, then I got it now... Sure, I just read the
post from Ted Tso again, use-ediff-instead.el, aha.
I guess it would be cleaner to do this in ~/.gitconfig:
[diff]
tool = ediff
[difftool "ediff"]
cmd = emacs --options "$LOCAL" "$REMOTE"
Which is annoying, of course.
But now that I got it (see above) I think you should leave
merge.tool=emerge, since the snippet somehow seems to rely on it.
> but it
> would require that mergetool library is changed
What's wrong with that?
If this solves the 'ediff' problem and also makes 'emerge' to work right
as difftool, then everyone would benefit from.
> 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.
Above you want your ediff mergetool snippet to work with difftool. And
here you want to use difftool as a mergetool. I'm confused :)
BTW, difftool doesn't work with files in unmerged state.
Markus
next prev parent reply other threads:[~2009-04-29 20:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-29 16:15 Diftool problems Marcin Zalewski
2009-04-29 19:42 ` Markus Heidelberg
2009-04-29 19:55 ` Marcin Zalewski
2009-04-29 20:48 ` Markus Heidelberg [this message]
2009-04-29 21:37 ` Marcin Zalewski
2009-05-02 9:05 ` David Aguilar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200904292248.06107.markus.heidelberg@web.de \
--to=markus.heidelberg@web$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=marcin.zalewski@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox