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

From: Jeff King <peff@peff.net>
Date: Apr 25, 2016, 21:37 UTC
Message-ID: <20160425213720.GB11227@sigill.intra.peff.net>
In-Reply-To: <20160425211506.8421-1-mtzguido@gmail.com>

On Mon, Apr 25, 2016 at 11:15:05PM +0200, Guido Martínez wrote:

Show 13 quoted lines

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

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

-Peff