From: William Hatfield Date: Mon, 02 Feb 2026 21:02:16 GMT Subject: Re: [PATCH 0/5] submodule: add 'reversive' traversal options to foreach Message-ID: <1F5D3AAF-3E5E-4AD0-A48B-90B9D545FB21@gmail.com> In-Reply-To: > On Feb 2, 2026, at 1:52 PM, Junio C Hamano wrote: > > William Hatfield writes: > >> This series introduces robust post-order (dependency-ordered) traversal to >> `git submodule foreach` through three new flags: `--reverse-traversal`, >> `--append-superproject`, and the shorthand `--reversive`. These options allow >> users to process nested submodules before their parents and include the >> superproject in the operation, enabling reliable automation for >> dependency-ordered cleanup, builds, and deployment workflows. >> >> Highlights: >> - Implements all new traversal flags in both the C helper and shell script. >> - Provides a comprehensive test suite (t7425) that validates the new behaviors. >> - Updates documentation to describe the new options and their intended use. >> >> These changes make submodule automation more powerful and flexible for advanced >> and dependency-sensitive use cases. > > A few comments on the overall structure and concepts. > > * We do not want to see tests in a commit separate from the commit > that fixes. The downside of such a layout of a series needs to > be understood. An earlier step of a series may introduce a line > with "test_expect_failure" plus a short summary of what the piece > fixes, followed by a large amount of code to show exactly what is > being tested and expected outcome. But when reading the step > that comes later that fixes the issue, readers will only see > changes from "test_expect_failure" to "test_expect success" with > most of the test to remind them what the issue was hidden away > from the view, in the post-context of patch hunk. A commit that > has both the fix and the test that describes the expectation is > much easier to work with. > > * The name "--reverse-traversal" makes sense only to those who know > what the normal traversal order is, but it is far from clear what > the normal submodule traversal order is, because there is no > "natural" order to traverse. Any of the combination of "top > down/bottom up" "width first/depth first" would make sense > depending on the application. If you are doing "bottom up", for > example, please name it as such. > > * The name "--append-superproject" sounds strange. It sounds as if > you are appending the superproject to something else, but I > suspect that is not what is happening; instead perhaps you are > leaving the traversal of the superproject at the end, or > something? > > Thanks. Thank you for the feedback, I will apply it in regard to test fixes in the same commit. Do you have any recommendation regarding names of these flags? Do you have a preference for: —postorder-traversal or —bottom-up-traversal? What about: —include-superpoject or —execute-in-superproject-last?