From: David Aguilar <davvid@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
Armin Kunaschik <megabreit@googlemail.com>,
Git List <git@vger.kernel.org>
Subject: Re: t7610-mergetool.sh test failure
Date: Thu, 26 May 2016 21:40:27 -0700 [thread overview]
Message-ID: <20160527044027.GA26143@gmail.com> (raw)
In-Reply-To: <20160526015114.GA12851@sigill.intra.peff.net>
On Wed, May 25, 2016 at 08:51:14PM -0500, Jeff King wrote:
> On Wed, May 25, 2016 at 06:16:15PM -0500, Jeff King wrote:
>
> > On Tue, May 24, 2016 at 09:45:25AM -0700, Junio C Hamano wrote:
> >
> > > On Tue, May 24, 2016 at 9:44 AM, Armin Kunaschik
> > > <megabreit@googlemail.com> wrote:
> > > > t7610-mergetool.sh fails on systems without mktemp.
> > > >
> > > > mktemp is used in git-mergetool.sh and throws an error when it's not available.
> > > > error: mktemp is needed when 'mergetool.writeToTemp' is true
> > > >
> > > > I see 2 options:
> > > > 1. code around it, write an own mktemp, maybe use the test-mktemp as a basis.
> > > > 2. disable the test when mktemp is not available
> > >
> > > 3. find and install mktemp?
> >
> > I'd agree more with (3) if it was some critical part of git-mergetool.
> > But it seems to be a completely optional feature that we use in only one
> > place, and git-mergetool even detects this case and complains.
> >
> > So another alternative would be for the test to detect either that
> > mergetool worked, or that we got the "mktemp is needed" error.
>
> BTW, one thing I happened to note while looking at this: running the
> test script will write into /tmp (or wherever your $TMPDIR points).
> Probably not a big deal, but I wonder if we should be setting $TMPDIR in
> our test harness.
We already set $HOME and various other variables to carefully
tune the testsuite's behavior, so this sounds like a good idea
IMO.
Would there be any downsides to setting $TMPDIR equal to the
trash directory?
FWIW I set $TMPDIR to the $TEST_OUTPUT_DIRECTORY in test-lib.sh
and was able to run the test suite without any errors.
Is it worth patching?
--
David
next prev parent reply other threads:[~2016-05-27 4:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-24 16:44 t7610-mergetool.sh test failure Armin Kunaschik
2016-05-24 16:45 ` Junio C Hamano
2016-05-24 16:53 ` Armin Kunaschik
2016-05-25 23:16 ` Jeff King
2016-05-26 1:51 ` Jeff King
2016-05-27 4:40 ` David Aguilar [this message]
2016-05-27 5:00 ` Jeff King
2016-05-27 6:33 ` Junio C Hamano
2016-05-27 18:24 ` Jeff King
2016-05-27 19:58 ` Junio C Hamano
2016-05-27 20:01 ` Jeff King
2016-06-22 16:53 ` Armin Kunaschik
2016-06-22 17:12 ` Jeff King
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=20160527044027.GA26143@gmail.com \
--to=davvid@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=megabreit@googlemail.com \
--cc=peff@peff.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.