Re: [PATCH v4] gitk: Use git-difftool for external diffs

David Aguilar, 2010-03-31 04:09:
> This teaches gitk about git-difftool. A benefit of this change
> is that gitk's external diff feature now works with read-only
> repositories.
>
> Signed-off-by: David Aguilar <[hidden email]>

Paul, you haven't replied yet but I do remember you mentioning
that you like to keep gitk backwards-compat with older git.
I have a newer version of this patch that checks for the
existence of difftool --extcmd=<cmd> before trying to use it.
It'll be PATCH v5.

git-difftool is used instead of the built-in external diff
code when git is >= 1.7.0. git-difftool's '--extcmd=frotz'
feature was first introduced in 1.7.0 and is the mechanism
through which we launch the configured difftool.

A benefit of this change is that gitk's external diff feature
no longer needs write-access to the current directory.

> git-difftool is used instead of the built-in external diff
> code when git is >= 1.7.0. git-difftool's '--extcmd=frotz'
> feature was first introduced in 1.7.0 and is the mechanism
> through which we launch the configured difftool.
>
> A benefit of this change is that gitk's external diff feature
> no longer needs write-access to the current directory.

I applied this one, and in testing it I noticed that if the git
difftool invocation fails, for example because the user doesn't have
meld installed, there is no notification via the GUI. Instead an
error message is printed to stderr. We need to do something more like
what we do in the old-git case -- use open rather than exec -- and pop
up an error dialog with error_popup on error so that the user knows
what the problem is.

Another minor problem is that the file names that meld (or other diff
tool) displays are less informative now. For example I see
"KyaZ5d_gitk : 8iucke_gitk" as the tab label in meld instead of the
"[87d24ec87abc...e236e0833ff] gitk" label that we got before, which
was a little more informative, though the e236e0833ff is the end of
the second SHA1 rather than the beginning.

So I backed it out. The error handling needs to be fixed using
something like what delete_at_eof does (except that obviously we don't
have any files to delete).

> On Thu, Apr 08, 2010 at 02:08:10AM -0700, David Aguilar wrote:
>
> > git-difftool is used instead of the built-in external diff
> > code when git is >= 1.7.0. git-difftool's '--extcmd=frotz'
> > feature was first introduced in 1.7.0 and is the mechanism
> > through which we launch the configured difftool.
> >
> > A benefit of this change is that gitk's external diff feature
> > no longer needs write-access to the current directory.
>
> I applied this one, and in testing it I noticed that if the git
> difftool invocation fails, for example because the user doesn't have
> meld installed, there is no notification via the GUI. Instead an
> error message is printed to stderr. We need to do something more like
> what we do in the old-git case -- use open rather than exec -- and pop
> up an error dialog with error_popup on error so that the user knows
> what the problem is.
>
> Another minor problem is that the file names that meld (or other diff
> tool) displays are less informative now. For example I see
> "KyaZ5d_gitk : 8iucke_gitk" as the tab label in meld instead of the
> "[87d24ec87abc...e236e0833ff] gitk" label that we got before, which
> was a little more informative, though the e236e0833ff is the end of
> the second SHA1 rather than the beginning.
>
> So I backed it out. The error handling needs to be fixed using
> something like what delete_at_eof does (except that obviously we don't
> have any files to delete).
>
> Paul.

I'll fix the error handling and add a few more notes to the
final commit message.

The title display is tool-specific so there's something we can
do about it on a tool-by-tool basis. This'll have to wait until
we can break out the tool-dependent parts of git-mergetool--lib
as was discussed in the past:

Jay, you mentioned wanting to give Junio's approach a try as
well as looking into what mercurial did with mergetools.
Do you have any thoughts about it since then? I can help
factor out the backends if you don't think you'll have time to
get to it soon.

Once we factor out the backends we'll should have an easier
time working in additional variables for doing user-friendly
things like passing the --label= flag to meld.
git-difftool should be able to do it since its GIT_EXTERNAL_DIFF
helper is passed the sha1s.

On Sat, Apr 17, 2010 at 6:45 PM, David Aguilar <[hidden email]> wrote:
> Jay, you mentioned wanting to give Junio's approach a try as
> well as looking into what mercurial did with mergetools.
> Do you have any thoughts about it since then? I can help
> factor out the backends if you don't think you'll have time to
> get to it soon.

Wow, I need to stop starting new patches and start finishing some of
the ones on my todo list.

But sorry, no, I haven't had a chance to look at this and I'm not
likely to soon. So if you've got the time and inclination, I'm happy
for you to do the work. :-)

[PATCH v6] gitk: Use git-difftool for external diffs when available

git-difftool's '--extcmd=frotz' was added in 1.7.0 and
is the mechanism through which gitk launches the
configured 'extdifftool'. When 'extdifftool' is
misconfigured an error dialog is used to display
git-difftool's stdout and stderr.

The existing implementation moved into 'proc gitkextdiff'
for use with git < 1.7.0.

One benefit of this change is that gitk's external diff
no longer requires write-access to the current directory.