Show 49 quoted lines
> On Feb 2, 2026, at 1:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> William Hatfield <whatfield.git@gmail.com> 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?