All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Aguilar <davvid@gmail.com>
To: Paul Mackerras <paulus@samba.org>
Cc: peff@peff.net, sam@vilain.net, git@vger.kernel.org
Subject: Re: [PATCH] gitk: Use git-difftool for external diffs
Date: Thu, 19 Nov 2009 11:39:15 -0800	[thread overview]
Message-ID: <20091119193913.GA25410@gmail.com> (raw)
In-Reply-To: <19205.2531.205062.980468@cargo.ozlabs.ibm.com>

On Thu, Nov 19, 2009 at 08:03:31PM +1100, Paul Mackerras wrote:
> David Aguilar writes:
> 
> > This teaches gitk about git-difftool.  A benefit of this change is
> > that gitk's external diff now works with read-only repositories.
> 
> What version of git does git difftool first appear in?  I prefer not
> to introduce hard requirements on very recent versions of git into
> gitk.
> 
> Paul.

git-difftool appeared in git 1.6.3.

If this patch is not going in then how do you suggest we fix the
read-only repository bug?

My immediate thought is to harden the $TMPDIR patch so that the
filenames used by gitk are much less predictable (I bailed on it
once Peff noted the $TMPDIR vulnerabilities and used
git-difftool instead since it is known to be safe).

Does hardening the $TMPDIR patch have a better chance of
being accepted?


In defense of difftool: there are more benefits to using
git-difftool than just read-only repositories.
The current external diff code does not work if 'meld'
is not installed whereas using git-difftool works by default
in more environments.  It also makes things match users'
expectations when they have already gone through the trouble
of configuring a diff or merge tool.

Is there a particular time frame in which such a patch could go
in?


My primary concern is getting gitk to work with read-only
repositories.  git-difftool was just one way of getting there.
If keeping backwards compatibility is a must-have then I can
hold onto the git-difftool patch until some time in the future
when it is more appropriate.  Hopefully something along the
lines of a hardened $TMPDIR patch can stand in for the final
fix in the meantime.

What do you think?

-- 
		David

  reply	other threads:[~2009-11-19 19:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-16  3:12 [PATCH] gitk: Use git-difftool for external diffs David Aguilar
2009-11-19  9:03 ` Paul Mackerras
2009-11-19 19:39   ` David Aguilar [this message]
2009-11-19 22:21     ` Paul Mackerras
2009-11-20  7:53       ` Junio C Hamano
2009-11-20 18:55         ` David Aguilar
2009-11-20 20:51           ` Junio C Hamano
2009-11-21 21:47             ` David Aguilar
2009-11-20 23:33           ` Markus Heidelberg
2009-12-30  3:13 ` Nanako Shiraishi
2009-12-30  7:49   ` Junio C Hamano
2009-12-31  7:16     ` David Aguilar
2009-12-31 20:37       ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2010-03-27 21:45 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=20091119193913.GA25410@gmail.com \
    --to=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=peff@peff.net \
    --cc=sam@vilain.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.