Re: [BUG?] push to mirrior interferes with parallel operations

From: Jeff King <peff@peff.net>
Date: Nov 18, 2010, 19:04 UTC
Message-ID: <20101118190414.GA30438@sigill.intra.peff.net>
In-Reply-To: <20101118184241.GN3693@efreet.light.src>

On Thu, Nov 18, 2010 at 07:42:41PM +0100, Jan Hudec wrote:

> The above config is what is created by default by 'git remote add --mirror'.
> So I expect the problem to be somewhat common with mirror and a lot rarer
> without.

Agreed, and I think just turning off the behavior with "mirror" might be OK in practice. But I do want to consider whether we can make other corner cases more sensible at the same time.

> Which brings the yet another question, namely whether it actually makes sense
> to set the fetch for a mirror remote. Note that any call to fetch will almost
> inevitably abort with "reusing to pull to checked out ref in non-bare
> repository" error.

Hmm. Yeah, of the "fetch vs push mirror" distinction I made earlier, it really only makes sense to push from a non-bare repo, and to fetch into a bare repo.

Show 7 quoted lines

> [skip some thoughtful analysis which I agree with, but I think ends up
>  not being relevant]
>
> In fact the problem is not in the race, but in the fact, that push updates
> refs, that may have other purpose than tracking the particular remote. The
> problem is in some cases we don't know whether a ref is purely tracking
> *that* remote or not.

Yeah, you're right. I think the real problem is that we generally assume that by putting something on the RHS of a fetch refspec, it is used just for tracking the particular remote (especially when there is a "+" on the front!).

So the real solution is not having that fetch line.

> and the third option (similar to the first, but done at different point):
> 
>  3. Don't set 'fetch' for mirror remotes in non-bare repositories, since
>     non-bare repositories can't be treated as mirrors of something.

Of all the options, this is my favorite. It does what we want in the common cases, it's simple, and it still allows people to hand-config crazy stuff if they want to.

It doesn't un-break people's existing repos, but I think we can accept that (actually, the docs say that --mirror only makes sense in bare repositories. Which I think is not true, as you demonstrate, but perhaps it dissuaded people from creating broken push mirrors in the past :) ).

That does still leave one slight corner case, which is a bare repo that is used for both fetch and push mirrors. E.g., a repo that straddles the border between two networks might do:

  git init --bare
  git remote add --mirror network1 host.network1:foo.git
  git remote add --mirror network2 host.network2:foo.git

  git fetch network1
  git push network2

to relay commits. Both remotes will have the fetch refspec, as they are in a bare repo. But only the first one wants it. In the second one, we will update the heads as tracking refs. A simultaneous fetch/push would be in conflict.

That is such an unlikely case that we can probably just leave it to be hand-configured by anybody who really wants it. Or we can have:

  # adds fetch = refs/*:refs/*
  git remote add --mirror=fetch network1 host.network1:foo.git
  # adds push = refs/*:refs/*
  git remote add --mirror=push network2 host.network2:foo.git

and the default for --mirror (with no type) can be "fetch" in a bare repo and "push" in a non-bare one.

-Peff