W dniu 21.10.2016 o 21:03, Junio C Hamano pisze: > Stefan Beller <sbeller@xxxxxxxxxx> 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. Push is/should be 'update all', fetch is/should be 'fetch any'. I thought that multiple remote.<name>.url values provide this fallback for fetch, but it looks like it isn't so... > > 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. One would need to configure fallback B remote to use the same remote-branch namespace as remote A, if it is to be used as fallback, 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. Nb. there is also http-alternates mechanism... which nowadays doesn't matter anyway, I would think. -- Jakub Narębski