From: Jeff King <email@example.com> To: Jacob Keller <firstname.lastname@example.org> Cc: Git mailing list <email@example.com> Subject: Re: avoiding fetching specific refs from a remote Date: Thu, 13 Aug 2020 04:48:15 -0400 [thread overview] Message-ID: <20200813084815.GA3092220@coredump.intra.peff.net> (raw) 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: > 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
prev parent 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200813084815.GA3092220@coredump.intra.peff.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: avoiding fetching specific refs from a remote' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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: https://80x24.org/mirrors/git.git 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).