{"thread":{"id":"32833","subject":"Re: Is anyone working on a next-gen Git protocol (Re: [PATCH v3 0/8] Hiding refs)","startedAt":"2013-02-05T11:14:32Z","lastAt":"2013-02-05T20:07:45Z","messageCount":3,"participants":["Ævar Arnfjörð Bjarmason","Junio C Hamano"],"isPatch":true,"patchVersion":3,"patchTotal":8},"messages":[{"id":"208704","messageId":"CACBZZX7G=V9L+zEA2MQFjQW8tRA0i1Gk3nUYdg5dDy35v74SEw@mail.gmail.com","threadId":"32833","inReplyTo":null,"subject":"Re: Is anyone working on a next-gen Git protocol (Re: [PATCH v3 0/8] Hiding refs)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2013-02-05T11:14:32Z","receivedAt":"2013-02-05T11:14:32Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Jan 30, 2013 at 7:45 PM, Junio C Hamano wrote:\n> The third round.\n>\n> - Multi-valued variable transfer.hiderefs lists prefixes of ref\n> hierarchies to be hidden from the requests coming over the\n> network.\n>\n> - A configuration optionally allows uploadpack to accept fetch\n> requests for an object at the tip of a hidden ref.\n>\n> Elsewhere, we discussed \"delaying ref advertisement\" (aka \"expand\n> refs\"), but it is an orthogonal feature and this \"hiding refs\n> completely from advertisement\" series does not attempt to address.\n\nI'm a bit late to this so sorry if this has been covered before.\n\nIn the initial draft of this series the rationale for it was \"reducing\nthe network cost while talking with a repository with tons of\nrefs\"[1]. But later you seem to have changed your mind, and \"network\nbandwidth reduction of advertisement is a side effect of clutter\nreduction, and not necessarily the primary goal\".\n\nDo you have any plans for something that *does* have the reduction of\nnetwork bandwidth as a primary goal?\n\nIn October I asked if anyone was working on a next-gen Git protocol[3]\nthat would provide clients with the ability to specify what refs they\nwanted. You replied to me off-list saying \"Yes\".\n\nIs this what you've been working on? Because if so I misunderstood you\nthinking you were going to work on something that gave clients the\nability specify what they wanted before the initial ref advertisement.\n\nI'm still very keen to have that ability, so if you're not working on\nit I just might give it a go.\n\n1. http://article.gmane.org/gmane.comp.version-control.git/213951\n2. http://article.gmane.org/gmane.comp.version-control.git/213984\n3. http://article.gmane.org/gmane.comp.version-control.git/214025\n4. http://thread.gmane.org/gmane.comp.version-control.git/207190\n"},{"id":"208734","messageId":"7vfw1avjcw.fsf@alter.siamese.dyndns.org","threadId":"32833","inReplyTo":"CACBZZX7G=V9L+zEA2MQFjQW8tRA0i1Gk3nUYdg5dDy35v74SEw@mail.gmail.com","subject":"Re: Is anyone working on a next-gen Git protocol (Re: [PATCH v3 0/8] Hiding refs)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-05T16:03:11Z","receivedAt":"2013-02-05T16:03:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> Do you have any plans for something that *does* have the reduction of\n> network bandwidth as a primary goal?\n\nUncluttering gives reduction of bandwidth anyway, so I do not see\nmuch point in the distinction you seem to be making.\n\n> Is this what you've been working on? Because if so I misunderstood you\n> thinking you were going to work on something that gave clients the\n> ability specify what they wanted before the initial ref advertisement.\n> ...\n> 4. http://thread.gmane.org/gmane.comp.version-control.git/207190\n\n\"Who speaks first\" mentioned in 4. above, was primarily about\n\"delaying ref advertisement\", which would be a larger protocol\nchange. Nobody seems to have attacked it since it was discussed,\nand I was tired of hearing nothing but complaints and whines. This\n\"hiding refs\" series was done as a cheaper way to solve a related\nissue, without having to wait for the solution of \"delaying\nadvertisement\", which is an orthogonal issue.\n"},{"id":"208756","messageId":"CACBZZX6bKJPRio6992xMK+fK3G+M2_HZ4NG=gShwfDHKRQEE+A@mail.gmail.com","threadId":"32833","inReplyTo":"7vfw1avjcw.fsf@alter.siamese.dyndns.org","subject":"Re: Is anyone working on a next-gen Git protocol (Re: [PATCH v3 0/8] Hiding refs)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2013-02-05T20:07:45Z","receivedAt":"2013-02-05T20:07:45Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Feb 5, 2013 at 5:03 PM, Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> Do you have any plans for something that *does* have the reduction of\n>> network bandwidth as a primary goal?\n>\n> Uncluttering gives reduction of bandwidth anyway, so I do not see\n> much point in the distinction you seem to be making.\n\nDoing this work wouldn't only give us a way to specify which refs we\nwant, but if done correctly would future-proof the protocol in case we\nwant to add any other extensions down the line in a\nbackwards-compatible fashion without having the server first spew all\nhis refs at us.\n\nAnyway, an implementation that allows a client to say \"I want X\" is\nsimpler than an implementation where a server has to anticipate in\nadvance which X the clients will ask for.\n\n>> Is this what you've been working on? Because if so I misunderstood you\n>> thinking you were going to work on something that gave clients the\n>> ability specify what they wanted before the initial ref advertisement.\n>> ...\n>> 4. http://thread.gmane.org/gmane.comp.version-control.git/207190\n>\n> \"Who speaks first\" mentioned in 4. above, was primarily about\n> \"delaying ref advertisement\", which would be a larger protocol\n> change. Nobody seems to have attacked it since it was discussed,\n> and I was tired of hearing nothing but complaints and whines. This\n> \"hiding refs\" series was done as a cheaper way to solve a related\n> issue, without having to wait for the solution of \"delaying\n> advertisement\", which is an orthogonal issue.\n\nOh sure. I just wanted to know if you were working on delaying ref\nadvertisement to avoid duplicating efforts. I had the impression you\nwere given your earlier E-Mail, but obviously we had a\nmisunderstanding.\n"}]}