Jeff King <p...@peff.net> 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
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 "remotes.foo=bar" 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.
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