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