CINXE.COM

<html><head><title>Re: [RFC 00/14] Allow fetch-pack to send ref names (globs allowed) - Jeff King</title><link rel=alternate title="Atom feed" href="../new.atom" type="application/atom+xml"/><style>pre{white-space:pre-wrap}*{font-size:100%;font-family:monospace}*{font-size:100%;font-family:monospace;background:#000;color:#ccc}pre{white-space:pre-wrap}a:link{color:#69f;text-decoration:none}a:visited{color:#96f}*.q{color:#09f}*.add{color:#0ff}*.del{color:#f0f}*.head{color:#fff}*.hunk{color:#c93}.hl.num{color:#f30}.hl.esc{color:#f0f}.hl.str{color:#f30}.hl.ppc{color:#f0f}.hl.pps{color:#f30}.hl.slc{color:#09f}.hl.com{color:#09f}.hl.kwa{color:#ff0}.hl.kwb{color:#0f0}.hl.kwc{color:#ff0}*{font-size:100%;font-family:monospace;background:#fff;color:#003}pre{white-space:pre-wrap}a:link{color:#00f;text-decoration:none}a:visited{color:#808}*.q{color:#006}*.add{color:#060}*.del{color:#900}*.head{color:#000}*.hunk{color:#960}.hl.num{color:#f30}.hl.esc{color:#f0f}.hl.str{color:#f30}.hl.ppc{color:#c3c}.hl.pps{color:#f30}.hl.slc{color:#099}.hl.com{color:#099}.hl.kwa{color:#f90}.hl.kwb{color:#060}.hl.kwc{color:#f90}</style><link type=text/css rel=stylesheet href=../216light.css?641f7afc media=print /></head><body><form action="../"><pre><a href="../?t=20170126230124"><b>git@vger.kernel.org mailing list mirror (one of many)</b></a> <input name=q type=text /><input type=submit value=search /> <a href="../_/text/help/">help</a> / <a href="../_/text/color/">color</a> / <a id=mirror href="../_/text/mirror/">mirror</a> / <a href=#code>code</a> / <a href="../new.atom">Atom feed</a></pre></form><pre id=b>From: Jeff King <peff@peff.net> To: Jonathan Tan <jonathantanmy@google.com> Cc: <a href="https://public-inbox.org/git/?t=20170126230124">git@vger.kernel.org</a> Subject: <a href="#r" id=t>Re: [RFC 00/14] Allow fetch-pack to send ref names (globs allowed)</a> Date: Thu, 26 Jan 2017 18:00:46 -0500 <a href="#r">[thread overview]</a> Message-ID: <20170126230046.aknesybfyzxhx3ia@sigill.intra.peff.net> (<a href="raw">raw</a>) In-Reply-To: <<a href="../cover.1485381677.git.jonathantanmy@google.com/">cover.1485381677.git.jonathantanmy@google.com</a>> On Wed, Jan 25, 2017 at 02:02:53PM -0800, Jonathan Tan wrote: <span class="q">> Negotiation currently happens by upload-pack initially sending a list of > refs with names and SHA-1 hashes, and then several request/response > pairs in which the request from fetch-pack consists of SHA-1 hashes > (selected from the initial list). Allowing the request to consist of > names instead of SHA-1 hashes increases tolerance to refs changing > (due to time, and due to having load-balanced servers without strong > consistency), </span> Interesting. My big question is: what happens when a ref _does_ change? How does the client handle this? The existing uploadpack.allowReachableSHA1InWant is there to work around the problem that an http client may get a ref advertisement in one step, and then come back later to do the want/have negotiation, at which point the server has moved on (or maybe it's even a different server). There the client says "I want sha1 X", and the server needs to say "well, X isn't my tip now, but it's still acceptable for you to fetch". But this seems to go in the opposite direction. After the advertisement, the client decides "OK, I want to fetch refs/heads/master which is at SHA1 X". It connects to the server and says "I want refs/heads/master". Let's say the server has moved its version of the ref to SHA1 Y. What happens? I think the server will say "wanted-ref master Y". Does the client just decide to use "Y" then? How does that interact with any decisions the client might have made about X? I guess things like fast-forwards have to be decided after we fetch the objects anyway (since we cannot compute them until we get the pack), so maybe there aren't any such decisions. I haven't checked. <span class="q">> and is a step towards eliminating the need for the server > to send the list of refs first (possibly improving performance). </span> I'm not sure it is all that useful towards that end. You still have to break compatibility so that the client tells the server to suppress the ref advertisement. After that, it is just a question of asking for the refs. And you have two options: 1. Ask the server to tell you the values of some subset of the refs, pick what you want, and then do the want/have as normal. 2. Go straight to the want/have, but tell the server the refs you want instead of their sha1s. I think your approach here would lead to (2). But (1), besides being closer to how the protocol works now, seems like it's more flexible. I can ask about the ref state without necessarily having to retrieve the objects. How would you write git-ls-remote with such a system? <span class="q">> [1] There has been some discussion about whether the server should > accept partial ref names, e.g. [2]. In this patch set, I have made the > server only accept full names, and it is the responsibility of the > client to send the multiple patterns which it wants to match. Quoting > from the commit message of the second patch: > > For example, a client could reasonably expand an abbreviated > name "foo" to "want-ref foo", "want-ref refs/heads/foo", "want-ref > refs/tags/foo", among others, and ensure that at least one such ref has > been fetched. </span> That has a cost that scales linearly with the number of refs, because you have to ask for each name 6 times. After the discussion you linked, I think my preference is more like: 1. Teach servers to accept a list of patterns from the client which will be resolved in order. Unlike your system, the client only needs to specify the list once per session, rather than once per ref. 2. (Optional) Give a shorthand for the stock patterns that git has had in place for years. That saves some bytes over specifying the patterns completely (though it's really not _that_ many bytes, so perhaps the complication isn't a big deal). -Peff </pre><hr><pre><a href="../67afbb3b-5d0b-8c0d-3f6e-3f559c68f4bd@google.com/" rel=next>next</a> <a href="../CAGZ79kZgx1wQSCQv2xHYK341+nb=EOSTZacoznebNE=_M3JweQ@mail.gmail.com/" rel=prev>prev</a> <a href="../cover.1485381677.git.jonathantanmy@google.com/">parent</a> <a href="#R">reply</a><a id=related> </a>other threads:[<a href="../?t=20170126230124">~2017-01-26 23:01 UTC</a>|<a href="../">newest</a>] <b>Thread overview: </b>31+ messages / expand[<a href="T/#u">flat</a>|<a href="t/#u">nested</a>] <a href="t.mbox.gz">mbox.gz</a> <a href="t.atom">Atom feed</a> <a href="#b">top</a> 2017-01-25 22:02 <a href="../cover.1485381677.git.jonathantanmy@google.com/">[RFC 00/14] Allow fetch-pack to send ref names (globs allowed)</a> Jonathan Tan 2017-01-25 22:02 ` <a href="../be83ed22dbea03511bf8f8fe830ca0a365128c05.1485381677.git.jonathantanmy@google.com/">[RFC 01/14] upload-pack: move parsing of "want" line</a> Jonathan Tan 2017-01-25 22:02 ` <a href="../d0d42b3bb4cf755f122591e191354c53848f197d.1485381677.git.jonathantanmy@google.com/">[RFC 02/14] upload-pack: allow ref name and glob requests</a> Jonathan Tan 2017-01-26 22:23 ` <a href="../xmqqd1f931g7.fsf@gitster.mtv.corp.google.com/">Junio C Hamano</a> 2017-01-27 0:35 ` <a href="../dc09e446-6d29-8b94-f440-6aa094ab9dc9@google.com/">Jonathan Tan</a> 2017-01-27 1:54 ` <a href="../xmqqinp11d3p.fsf@gitster.mtv.corp.google.com/">Junio C Hamano</a> 2017-01-25 22:02 ` <a href="../afe5d7d3f876893fdad318665805df1e056717c6.1485381677.git.jonathantanmy@google.com/">[RFC 03/14] upload-pack: test negotiation with changing repo</a> Jonathan Tan 2017-01-26 22:33 ` <a href="../xmqq8tpx30zq.fsf@gitster.mtv.corp.google.com/">Junio C Hamano</a> 2017-01-27 0:44 ` <a href="../0c727063-0583-f713-68fb-bd284be696b2@google.com/">Jonathan Tan</a> 2017-02-22 23:36 ` <a href="../xmqqo9xtajcu.fsf@gitster.mtv.corp.google.com/">Junio C Hamano</a> 2017-02-23 18:43 ` <a href="../20170223184303.26530-1-jonathantanmy@google.com/">[PATCH] upload-pack: report "not our ref" to client</a> Jonathan Tan 2017-02-23 20:14 ` <a href="../xmqqshn47jgs.fsf@gitster.mtv.corp.google.com/">Junio C Hamano</a> 2017-01-25 22:02 ` <a href="../057e40c56d7bbaf581c9552b45315087cb0f5ed3.1485381677.git.jonathantanmy@google.com/">[RFC 04/14] fetch: refactor the population of hashes</a> Jonathan Tan 2017-01-25 22:02 ` <a href="../17158edf664fc85ae52da66e3de9210a2a645f14.1485381677.git.jonathantanmy@google.com/">[RFC 05/14] fetch: refactor fetch_refs into two functions</a> Jonathan Tan 2017-01-25 22:02 ` <a href="../4fc5ef88ae2135db475c557498e7a805afb693b9.1485381677.git.jonathantanmy@google.com/">[RFC 06/14] fetch: refactor to make function args narrower</a> Jonathan Tan 2017-01-25 22:03 ` <a href="../86a128c5fb710a41791e7183207c4d64889f9307.1485381677.git.jonathantanmy@google.com/">[RFC 07/14] fetch-pack: put shallow info in out param</a> Jonathan Tan 2017-01-25 22:03 ` <a href="../b722c0e310305a7eb4013209122db3a0c7b2052c.1485381677.git.jonathantanmy@google.com/">[RFC 08/14] fetch-pack: check returned refs for matches</a> Jonathan Tan 2017-01-25 22:03 ` <a href="../27ff4202986d2bb88705f37cab33f171df1427a2.1485381677.git.jonathantanmy@google.com/">[RFC 09/14] transport: put ref oid in out param</a> Jonathan Tan 2017-01-25 22:03 ` <a href="../8e8ff3cbd7276233e712b4d0049e709c2372cfd7.1485381677.git.jonathantanmy@google.com/">[RFC 10/14] fetch-pack: support partial names and globs</a> Jonathan Tan 2017-01-25 22:03 ` <a href="../7b01ee955db8b2d9c6c7e641f7f09436938b2af4.1485381677.git.jonathantanmy@google.com/">[RFC 11/14] fetch-pack: support want-ref</a> Jonathan Tan 2017-01-25 22:03 ` <a href="../db1db5d0e5563464c09d1678234c9c5e8ae5b2f4.1485381677.git.jonathantanmy@google.com/">[RFC 12/14] fetch-pack: do not printf after closing stdout</a> Jonathan Tan 2017-01-26 0:50 ` <a href="../CAGZ79kb+VVQoimCDCxk1JPtVdDcS0vgi3NgVfo_aZ_=feed8Cw@mail.gmail.com/">Stefan Beller</a> 2017-01-26 18:18 ` <a href="../bcdeacb6-4517-b3de-cafe-27540dd4f7d0@google.com/">Jonathan Tan</a> 2017-01-25 22:03 ` <a href="../eef2b77d88df0db08e4a1505b06e0af2d40143d5.1485381677.git.jonathantanmy@google.com/">[RFC 13/14] fetch: send want-ref and receive fetched refs</a> Jonathan Tan 2017-01-25 22:03 ` <a href="../a2262f625eb68cadc82ce042372111c05b4aca32.1485381677.git.jonathantanmy@google.com/">[RFC 14/14] DONT USE advertise_ref_in_want=1</a> Jonathan Tan 2017-01-26 22:15 ` <a href="../CAGZ79kZgx1wQSCQv2xHYK341+nb=EOSTZacoznebNE=_M3JweQ@mail.gmail.com/">[RFC 00/14] Allow fetch-pack to send ref names (globs allowed)</a> Stefan Beller <b>2017-01-26 23:00 ` <a id=r href="#t">Jeff King [this message]</a></b> 2017-01-27 0:26 ` <a href="../67afbb3b-5d0b-8c0d-3f6e-3f559c68f4bd@google.com/">Jonathan Tan</a> 2017-02-07 23:53 ` <a href="../20170207235350.10718-1-jonathantanmy@google.com/">Jonathan Tan</a> 2017-02-09 0:26 ` <a href="../xmqq7f50tdja.fsf@gitster.mtv.corp.google.com/">Junio C Hamano</a> -- strict thread matches above, loose matches on Subject: below -- 2018-05-20 8:24 <a href="../596688AA-4A32-4A6B-8732-477E79D8934D@icloud.com/">Apinan Ponchan</a> </pre><hr><pre id=R><b>Reply instructions:</b> You may reply publicly to <a href=#t>this message</a> 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: <a href=raw>mbox</a> Avoid top-posting and favor interleaved quoting: <a href="https://en.wikipedia.org/wiki/Posting_style#Interleaved_style">https://en.wikipedia.org/wiki/Posting_style#Interleaved_style</a> List information: <a href="http://vger.kernel.org/majordomo-info.html">http://vger.kernel.org/majordomo-info.html</a> * Reply using the <b>--to</b>, <b>--cc</b>, and <b>--in-reply-to</b> switches of git-send-email(1): git send-email \ --in-reply-to=20170126230046.aknesybfyzxhx3ia@sigill.intra.peff.net \ --to=peff@peff.net \ --cc=git@vger.kernel.org \ --cc=jonathantanmy@google.com \ /path/to/YOUR_REPLY <a href="https://kernel.org/pub/software/scm/git/docs/git-send-email.html">https://kernel.org/pub/software/scm/git/docs/git-send-email.html</a> * If your mail client supports setting the <b>In-Reply-To</b> header via mailto: links, try the <a href="mailto:peff@peff.net?In-Reply-To=%3C20170126230046.aknesybfyzxhx3ia@sigill.intra.peff.net%3E&Cc=git%40vger.kernel.org%2Cjonathantanmy%40google.com&Subject=Re%3A%20%5BRFC%2000%2F14%5D%20Allow%20fetch-pack%20to%20send%20ref%20names%20%28globs%20allowed%29">mailto: link</a> </pre> Be sure your reply has a <b>Subject:</b> header at the top and a blank line before the message body. <hr><pre><a id=code>Code repositories for project(s) associated with this public inbox <a href="https://80x24.org/mirrors/git.git">https://80x24.org/mirrors/git.git</a> This is a public inbox, see <a href="../_/text/mirror/">mirroring instructions</a> 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).</pre></body></html>