Jay Soffian <jaysoff...@gmail.com> writes:

> Teach "git submodule foreach" a --revision <tree-ish> option. This
> is useful in combination with $sha1 to perform git commands that
> take a revision argument.

The above says:

 - "--revision T" is added.

   OK.  There is no information whatsoever what it does to convince
   us why it is useful.

 - This is useful.

   Huh?  How can anybody supposed to agree or disagree with that
   claim, when nothing is said about what it does in the first

> For example:
>   $ git submodule foreach --revision v1.0 'git tag v1.0 $sha1'

Whose "v1.0" does this example refer to?

The first line of the proposed log message says it is <tree-ish>,
which means that you can safely substitute "--revision T" with
"--revision $(git rev-parse T^{tree}), so it must name a concrete
single object that is a tree (not a tree-ish).  In which repository
is that object found?  The top-level superproject?  All submodule
repositories share the same object store with the superproject?

The description doesn't make _any_ sense to me. The feature might be
something worth considering about with a better description, but
with the above, I can't tell if it is.

> +     If `--revision <tree-ish>` is given, submodules are traversed starting
> +     at the given <tree-ish>.

What does "are traversed starting at the given <tree-ish>"?  The
desired or expected state of each submodule is recorded as a commit
object name (not even commit-ish) in its superproject.  Did you mean

> + Though this does not alter the submodule check
> +     outs, it may be combined with $sha1 to perform git commands that can
> +     operate on a particular commit, such as linkgit:git-tag[1].

Here is what I am guessing, partially with help from the horrible example:

>   $ git submodule foreach --revision v1.0 'git tag v1.0 $sha1'
> Previously, this would have required multiple steps:
>   $ git checkout v1.0
>   $ git submodule update
>   $ git submodule foreach 'git tag v1.0'

where there appears two v1.0 that are used for totally different
purposes which does not help guessing.  Perhaps "--revision" names a
tree-ish taken from the top-level superproject, and for each
submodule that appear in the tree in the superproject, the command
specified by foreach is run with the usual $sha1, $name, $path set
to the state in the submodules that top-level tree wants to have,
and this is done without actually checking anything out.  So the
first v1.0 in that confusing example is about specifying a tree in
the superproject repository, and the second v1.0 does not have any
relationship with that first v1.0 (the first one could have been HEAD~2
when you have committed twice in the superproject since you tagged v1.0
and remembered that you forgot to tag its submodules).

Assuming that the above guess is correct (which is a huge
assumption, given the lack of clarity in the description), I think
the feature might make sense.  The example would have been a lot
easier to follow if it were something like this:

    $ git submodule foreach --revision v1.0 'git grep -e frotz $sha1'

> @@ -379,6 +379,7 @@ Use -f if you really want to add it." >&2
>  cmd_foreach()
>  {
>       # parse $args after "submodule ... foreach".
> +     revision=
>       while test $# -ne 0
>       do
>               case "$1" in
> @@ -388,6 +389,11 @@ cmd_foreach()
>               --recursive)
>                       recursive=1
>                       ;;
> +             --revision)
> +                     git rev-parse --quiet --verify "$2" >/dev/null || usage
> +                     revision=$2

Shouldn't this part of the code verify $2^{tree} instead to ensure
that "$2" is a tree-ish?

> +                     shift
> +                     ;;
>               -*)
>                       usage
>                       ;;
> @@ -404,7 +410,17 @@ cmd_foreach()
>       # command in the subshell (and a recursive call to this function)
>       exec 3<&0
> -     module_list |
> +     if test -n "$revision"
> +     then
> +             # make ls-tree output look like ls-files output
> +             git ls-tree -r $revision | grep '^160000 ' |
> +             while read mode unused sha1 sm_path
> +             do
> +                     echo "$mode $sha1 0 $sm_path"
> +             done
> +     else
> +             module_list
> +     fi |

Hrm, it is somewhat unfortunate that you cannot limit the set of
submodules to apply foreach to, like other commands like init,
update, status, etc.  (not a new problem).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to