On Wed, Aug 12, 2020 at 03:04:09PM -0700, Jacob Keller wrote:
> 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
