From: Junio C Hamano Date: Mon, 02 Feb 2026 18:52:34 GMT Subject: Re: [PATCH 0/5] submodule: add 'reversive' traversal options to foreach Message-ID: In-Reply-To: <20260131214309.1899376-1-whatfield.git@gmail.com> 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.