list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: Jacob Keller <>
Cc: Git mailing list <>
Subject: Re: avoiding fetching specific refs from a remote
Date: Thu, 13 Aug 2020 04:48:15 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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

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


  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

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!


      reply	other threads:[~2020-08-13  8:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-04 21:53 Jacob Keller
2020-08-05  6:37 ` Jeff King
2020-08-05 16:22   ` Junio C Hamano
2020-08-05 20:34     ` Jacob Keller
2020-08-05 20:34     ` Jeff King
2020-08-05 20:31   ` Jacob Keller
2020-08-05 22:12   ` Philippe Blain
2020-08-07  8:04     ` Eric Wong
2020-08-12 22:04   ` Jacob Keller
2020-08-13  8:48     ` Jeff King [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: avoiding fetching specific refs from a remote' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).