Re: [RFC/PATCH] Ordering of remotes for fetch --all

["Guido Martínez" <mtzguido@gmail.com>]

Hi Jeff, thanks for your comments.

On Mon, Apr 25, 2016 at 11:37 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Apr 25, 2016 at 11:15:05PM +0200, Guido Martínez wrote:
>
>> I run a server with several git mirrors, that are updated every hour. On
>> that same server, users clone those projects and work on them. We use
>> the local mirrors to reduce network load: the users can fetch from the
>> mirror first (to get most of the objects with zero network cost) and
>> then fetch the real remote (to make sure they're completely up to date).
>>
>> I would like this to be configurable in each git working directory,
>> so users can just configure the order they want and then just do "git
>> remote update".
>>
>> I'm aware one can get this behavior by editing .git/config and
>> ordering the remotes as one wishes, but I find that very hacky and not
>> scripting-friendly.
>
> You can also define your own ordered groups, like:
>
>   $ git config remotes.foo "one two three"
>   $ git fetch foo 2>&1 | grep ^Fetching
>   Fetching one
>   Fetching two
>   Fetching three
>
> That's not _exactly_ the same, because you can't give a partial ordering
> of one high-priority remote and then say "all the rest, in whatever
> order you want", because there's no way to say "all the rest".
>
> You _can_ say:
>
>   git config remotes.foo "high-priority --all"
>
> but the final "--all" will fetch from high-priority again. An
> alternative feature would be to teach remotes.* groups to cull
> duplicates, if that's not acceptable.
These are good, but my main drive was to be able to just "git remote
update" without any more information. In your cases I need to call
update "foo". Also as you mention you either need to edit foo when
adding a repo, or duplicating the pull from the high-prio one.

Another approach would be to add a "fetchdep" pointing to another
remote, and then do a topological sort on fetch --all. This can also
be used on "git pull", to first pull from the mirror without any extra
command.

Maybe it's not such a big deal, but I think it's a nice feature to
have. It allows for a stupidly simple mirroring/prefetch scheme,
without any proxy or anything fancy.

Not sure if it suits the needs of anyone else, though... Would there
be interest in me implementing the "fetchdep" alternative?

Thanks!
Guido

>
> I don't have a strong opinion against your approach, though. Just
> exploring alternatives.
>
> -Peff