All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: Jeff King <peff@peff.net>, phillip.wood@dunelm.org.uk
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Subject: Re: Failing tests with WITH_BREAKING_CHANGES
Date: Wed, 29 Jul 2026 16:25:42 +0100	[thread overview]
Message-ID: <1ee46199-b895-4f5e-ba2b-030fb2e47852@gmail.com> (raw)
In-Reply-To: <20260728135532.GA11894@coredump.intra.peff.net>

On 28/07/2026 14:55, Jeff King wrote:
> On Tue, Jul 28, 2026 at 02:31:03PM +0100, Phillip Wood wrote:
> 
>> I find t1517 fails quite often for me due to cruft from a previous build
>> when a different branch was checked out. I wonder if there is a command that
>> is no-longer built by WITH_BREAKING_CHANGES whose executable still exists in
>> the build directory from a previous build. Its not clear to me why the alias
>> tests might be failing though.
> 
> It's the same reason. We test looping through deprecated aliases using
> whatchanged and pack-redundant. When those are builtin but deprecated
> (like now) we allow aliases. After the breaking-changes split, those
> names are not special at all, and they are subject to the usual alias
> rules. If there is crufty git-whatchanged in your build directory, then
> that is an "external command" unknown to Git and you are not allowed to
> alias over it.

Oh, of course - thanks for explaining that. Thanks for fixing the tests 
as well, I've only skimmed them but they seemed to make sense.

Phillip

> The test in t0014 that covers this should be removed after the breaking
> changes actually land (those commands won't handled specially, so it's
> not different than the normal alias loop detection).
> 
> But we are in a funny limbo now for WITH_BREAKING_CHANGES. Possibly we
> could pull the value out of GIT-BUILD-OPTIONS (which I guess happens
> already via the environment) and use a prereq to skip the test.
> 
> -Peff
> 


      parent reply	other threads:[~2026-07-29 15:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28  0:46 Failing tests with WITH_BREAKING_CHANGES brian m. carlson
2026-07-28  1:00 ` Junio C Hamano
2026-07-28 13:31 ` Phillip Wood
2026-07-28 13:55   ` Jeff King
2026-07-28 14:36     ` [PATCH 0/2] fix serial tests without/with breaking-changes Jeff King
2026-07-28 14:37       ` [PATCH 1/2] t0014: factor out choice of deprecated commands Jeff King
2026-07-28 15:57         ` Junio C Hamano
2026-07-28 14:38       ` [PATCH 2/2] t0014: generate deprecated command names dynamically Jeff King
2026-07-28 16:01         ` Junio C Hamano
2026-07-28 16:19           ` Jeff King
2026-07-28 21:12         ` brian m. carlson
2026-07-29 15:25     ` Phillip Wood [this message]

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=1ee46199-b895-4f5e-ba2b-030fb2e47852@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=sandals@crustytoothpaste.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.