Re: [PATCH 0/5] submodule: add 'reversive' traversal options to foreach

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 2, 2026, 18:52 UTC
Message-ID: <xmqqbji7yo3x.fsf@gitster.g>
In-Reply-To: <20260131214309.1899376-1-whatfield.git@gmail.com>

William Hatfield <whatfield.git@gmail.com> writes:

Show 14 quoted lines

> 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.