Jeff King <peff@xxxxxxxx> 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 "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. > > -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html