Re: [PATCH 2/2] t0014: generate deprecated command names dynamically

Jeff King <[email protected]> Tue, 28 Jul 2026 12:19:49 -0400
Newsgroups org.kernel.vger.git
Message-ID <[email protected]>
On Tue, Jul 28, 2026 at 09:01:53AM -0700, Junio C Hamano wrote:

> Jeff King <[email protected]> writes:
> 
> > We have a few tests related to aliasing of deprecated commands. They use
> > whatchanged and pack-redundant because those are the only two deprecated
> > commands we have. Eventually those commands will be removed, at which
> > point these tests will be checking nothing useful (they'll just be
> > regular aliases, which we already cover in other tests).
> >
> > We could remove them at that point, but the code to handle deprecated
> > commands will still remain. We probably do want to keep the tests around
> > for the eventual day that we deprecate more commands. So let's ask Git
> > for its list of deprecated commands, and if we don't have any, skip
> > those tests.
> 
> Ah, now I understand.  So HAVE_DEPRECATED prerequisite guards tests
> that require at least two deprecated commands, so that we can test
> cases with aliases that involve two commands among deprecated ones
> referring to each other.  Obviously, with 0 or 1 deprecated commands,
> there is no point to perform such tests.

Yeah. Sorry, maybe splitting the two just made it more confusing (it was
really to make the diff a bit less heinous). I'm OK if you want to just
squash them together (using the commit message from the second).

I suspect we could _probably_ rewrite the "looping aliases" test to also
run when there's only 1 deprecated command (just looping on itself). But
since we have two now, and plan to have zero later, I don't know that
it's worth the effort of doing so.

-Peff