All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org,  Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH] tests: prefer host Git to verify chainlint self-checks
Date: Wed, 13 Dec 2023 07:11:28 -0800	[thread overview]
Message-ID: <xmqqr0jqnnmn.fsf@gitster.g> (raw)
In-Reply-To: <ZXlbNlG28e1sAYPU@tanuki> (Patrick Steinhardt's message of "Wed, 13 Dec 2023 08:20:22 +0100")

Patrick Steinhardt <ps@pks.im> writes:

>> I do not think "prefer host Git" is necessarily a good idea; falling
>> back to use host Git is perfectly fine, of course.
>
> Why is that, though?

Mostly because your "differences in features supported by just-built
one and what happens to be on $PATH can cause problems" cuts both
ways, and as a general principle to work around such issues, using
just-built one is a better discipline.  The features the build
infrastructure ("self-checks" being discussed is a part of it) of a
particular version of Git source depends on are more likely to be
found in the binary that will be built from the matching source,
than what happens to be on $PATH that may be from a year-old version.

As you said, you'd need to accomodate need for those who are
initially porting or building Git on a host without an installed
one.  If we were doing a cross build where just-built on would not
be executable on the host, whatever version on $PATH (or in
/usr/bin) may have to be used, but then in such a case you would not
be testing on host anyway.  For these two reasons, it is a given
that one of the choices has to be to use just-built one.  We can
safely give lower precedence to the host tool.

The only one-and-half practical reasons we may want to fall back to
whatever happens to be on $PATH are:

 - just-built one is so broken that even the simple use by the build
   infrastructure (like "self-checks") does not work (but then it
   becomes "if it is so broken, fix it before even thinking about
   running tests", and that is why I count it as half a reason), or

 - we are bisecting down to an ancient version, and just-built one
   from such a version may not understand the current repository.

so I do think it is an excellent workaround to fall back to a
version of Git with unknown vintage that happens to be on $PATH,
than failing and stopping by relying only on just-built one.

> We already use host Git in other parts of our build
> infra, and the options we pass to git-diff(1) have been around for ages:

It only argues for "trying host one, if available, before just-built
one does not hurt for this particular case".  But I was interested
in laying out a more general principle we can follow in similar
situations in the future.

  reply	other threads:[~2023-12-13 15:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-12 11:32 [PATCH] tests: prefer host Git to verify chainlint self-checks Patrick Steinhardt
2023-12-12 19:30 ` Junio C Hamano
2023-12-13  7:20   ` Patrick Steinhardt
2023-12-13 15:11     ` Junio C Hamano [this message]
2023-12-14  3:33       ` Eric Sunshine
2023-12-14  8:13         ` Patrick Steinhardt
2023-12-14  8:39           ` Eric Sunshine
2023-12-14  8:40             ` Patrick Steinhardt
2023-12-14 16:16             ` Junio C Hamano
2023-12-14 18:10               ` Eric Sunshine
2023-12-14 19:13                 ` Junio C Hamano
2023-12-15  5:33                 ` Patrick Steinhardt
2023-12-14  8:30 ` [PATCH v2] tests: adjust whitespace in chainlint expectations Patrick Steinhardt
2023-12-14  8:44   ` Eric Sunshine
2023-12-15  6:04 ` [PATCH v3] " Patrick Steinhardt
2023-12-15  6:24   ` Eric Sunshine
2023-12-15  6:29     ` Patrick Steinhardt
2023-12-15  6:40       ` Eric Sunshine
2023-12-15  6:42 ` [PATCH v4] " Patrick Steinhardt
2023-12-15  7:17   ` Eric Sunshine
2023-12-15 16:44     ` Junio C Hamano

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=xmqqr0jqnnmn.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=ps@pks.im \
    --cc=sunshine@sunshineco.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.