Hi Jeff, thanks for your comments. On Mon, Apr 25, 2016 at 11:37 PM, Jeff King <peff@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html