Re: Fwd: Runaway "git remote" if group definition contains a remote by the same name

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 30, 2013, 19:10 UTC
Message-ID: <xmqqlhz2rw7s.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20131229075838.GC31788@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 14 quoted lines

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

Show 9 quoted lines

>   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