All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Johannes Sixt <j6t@kdbg.org>,
	Christian Couder <christian.couder@gmail.com>,
	git <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: "./t0001-init.sh --valgrind" is broken
Date: Thu, 03 Mar 2016 07:56:09 -0800	[thread overview]
Message-ID: <xmqqk2lj3692.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CACsJy8AE9VovwuviwOLxRDTAbTXCivRVhk8ia4mdUnMN-0Y4OA@mail.gmail.com> (Duy Nguyen's message of "Thu, 3 Mar 2016 19:16:55 +0700")

Duy Nguyen <pclouds@gmail.com> writes:

> On Thu, Mar 3, 2016 at 7:09 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> But it's probably better that we inject valgrind command
>> from inside bin-wrappers script, the same way we inject gdb, I think.
>
> For the best of both worlds, we should recreate bin-wrappers in
> test-lib.sh (i.e. the valgrind way), not in Makefile.
>
> Somewhat
> unrelated, but because topdir is getting really crowded and
> bin-wrappers is used for the test suite only, it should be moved
> inside t/ (i'm going to move all test-* to t/ too, later).

Weren't there people who pointed their bin-wrappers/ with $PATH to
test/use freshly baked Git before they convince themselves that they
want to install it?  Not building it from the top-level Makefile
and moving it to elsewhere would be two breakages for them.

I am not sure if that is a good idea.

Moving test-* sources out of the top-level is a good idea, and
placing test-* binaries somewhere other than the top-level is also a
good idea.  Just like t/lib-*.sh are helpers for tests, these are
also test helpers that happen to be written in C and compiled, so I
don't have a strong objection to make t/ the new location for
them--a different location (e.g. a new "test-helpers/" directory) is
also something I can go with.

Thanks.

In any case, are these two messages objections to J6t's fix, or are
you fine with the fix for 2.8-rc1 and merely raising ideas to redo
it in a different (i.e. your) way after 2.8 final, or are you
planning to do a fix in a different way for 2.8-rc1?

  reply	other threads:[~2016-03-03 15:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-03  0:07 "./t0001-init.sh --valgrind" is broken Christian Couder
2016-03-03  1:04 ` Duy Nguyen
2016-03-03  2:57   ` Junio C Hamano
2016-03-03  6:55   ` Johannes Sixt
2016-03-03 12:09     ` Duy Nguyen
2016-03-03 12:16       ` Duy Nguyen
2016-03-03 15:56         ` Junio C Hamano [this message]
2016-03-03 18:05       ` Jeff King
2016-03-03 18:17       ` Johannes Sixt

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=xmqqk2lj3692.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=pclouds@gmail.com \
    /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.