Re: RFC Failover url for fetches?

[Junio C Hamano <gitster@pobox.com>]

Stefan Beller <sbeller@google.com> writes:

> So when pushing it is possible to have multiple urls
> (remote.<name>.url) configured.
>
> When fetching only the first configured url is considered.
> Would it make sense to allow multiple urls and
> try them one by one until one works?

I do not think the two are related.  Pushing to multiple is not "I
want to update at least one of them" in the first place.

As to fetching from two or more places as "fallback", I am
moderately negative to add it as a dumb feature that does nothing
more than "My fetch from A failed, so let's blindly try it from B".
I'd prefer to keep the "My fetch from A is failing" knowledge near
the surface of end user's consciousness as a mechanism to pressure A
to fix it--that way everybody who is fetching from A benefits.
After all, doing "git remote add B" once (you'd need to tell the URL
for B anyway to Git) and issuing "git fetch B" after seeing your
regular "git fetch" fails once in a blue moon is not all that
cumbersome, I would think.

Some people _may_ have objection based on A and B going out of sync,
especially B may fall behind even yourself and cause non-ff errors,
but I personally am not worried about that, because when somebody
configures B as a fallback for A, there is an expectation that B is
kept reasonably up to date.  It would be a problem if some refs are
expected to be constantly rewound at A (e.g. 'pu' in my tree) and
configured to always force-fetch, though.  A stale B would silently
set such a branch in your repository back without failing.