Re: avoiding fetching specific refs from a remote

From: Jeff King <peff@peff.net>
Date: Aug 13, 2020, 08:48 UTC
Message-ID: <20200813084815.GA3092220@coredump.intra.peff.net>
In-Reply-To: <CA+P7+xp5aRWV0udmf03+ox4+8nCOmXtfEckmhJrAs-42Tomn0w@mail.gmail.com>

On Wed, Aug 12, 2020 at 03:04:09PM -0700, Jacob Keller wrote:

Show 7 quoted lines

> I dug up the patch and have applied it to master. One concern I have
> is how do we tell what side the negative refspec applies to? It seems
> like we'd need to be able to distinguish whether it applies to the
> refname on the remote, or the refname on the local branch. The patch
> as-is assumes that negative refspecs only ever have "src".. I guess
> for fetch that means the name of the ref on the remote, and for push
> that means the name of the ref on the local end?

Yeah, unlike a normal refspec that can have both a src and dst, there really is only one "side" to a negative refspec, because it is not going anywhere. So selecting by src makes the most sense to me. We could also allow selecting by dst, like:

  git fetch origin refs/heads/*:refs/remotes/origin/* \
    ^refs/heads/foo           \ (1) omit remote foo branch; implies src
    ^refs/heads/bar:          \ (2) omit remote bar branch by explicit src
    ^:refs/remotes/origin/baz   (3) omit remote baz branch by explicit dst

I probably wouldn't bother with (2) or (3) unless somebody really wants them. We can do (1) now and then extend later without loss of compatibility.

Another thing to think about is how to handle overlap. E.g., in:

  ^refs/heads/foo refs/heads/*:refs/remotes/origin/*

should:

  1. The first take precedence over the second because we apply
     positive, then negative?

  2. Or should it be first over second because the first is specific and
     the second is a wildcard?

  3. Or should it be second over first because later refspecs override
     earlier?

I don't have a real preference, and I think there are many self-consistent schemes you could come up with. But it probably makes sense to think it through so that we don't get stuck supporting a half-baked behavior later.

> I was trying to modify the patch to add support to the push code flows
> so that it was more complete and could be submitted. I'll be sending
> what I have as an RFC soon.

Sounds good. Thanks for picking this up!

-Peff