Jeff King <> writes:

> If they are not allowed to recurse, the problem is much easier; the
> parent fetch simply tells all of the sub-invocations not to expand the
> arguments further. However, whether it was planned or not, it has been
> this way for a long time. I would not be surprised if somebody is
> relying on the recursion to help organize their groups.
> So I think the sanest thing is probably:
>   1. Teach "fetch" to expand recursively in a single process, and then
>      tell sub-processes (via a new command-line option) not to expand
>      any further.
>   2. Teach "fetch" to detect cycles (probably just by a simple depth
>      counter).

I suspect that the expansion code will just accumulate remotes found
into a string-list (as part of 4. below), so deduping would be
fairly easily done without a depth counter.

>   3. Teach the group-reading code to detect groups more robustly, so
>      that a single-item group like "" correctly recurses
>      to "bar".

A single-item remote group is somewhat annoying, but expanding it
only at some places while ignoring it at other places is even more
annoying, so this sounds like a right thing to do.

>   4. (Optional) Teach the expansion code from step 1 to cull duplicates,
>      so that we do not try to fetch from the same remote twice (e.g., if
>      it is mentioned as part of two groups, and both are specified on
>      the command line).
> I do not plan to work on this myself in the immediate future, but
> perhaps it is an interesting low-hanging fruit for somebody else.
> -Peff
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to