git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Tan <jonathantanmy@google.com>
To: gitster@pobox.com
Cc: jonathantanmy@google.com, git@vger.kernel.org
Subject: Re: [PATCH 5/6] fetch: teach independent negotiation (no packfile)
Date: Fri,  9 Apr 2021 09:38:35 -0700	[thread overview]
Message-ID: <20210409163835.2560428-1-jonathantanmy@google.com> (raw)
In-Reply-To: <xmqqczv4nhem.fsf@gitster.g>

> Jonathan Tan <jonathantanmy@google.com> writes:
> 
> > There are 2 code paths that do not go through fetch_refs_via_pack() that
> > needed to be individually excluded: the bundle transport (excluded
> > through requiring smart_options, which the bundle transport doesn't
> > support) and transport helpers that do not support takeover.
> > Fortunately, none of these support protocol v2.
> 
> I am a bit puzzled by this mention of "Fortunately".  If one says
> "this shiny new feature only works with protocol v2" and "transport
> X does not support protocol v2", doesn't it imply that the shiny new
> feature cannot be used with the transport X, which is unfortunate?

I meant to say that we don't have to do much about these cases because
they are out of scope for the support that we planned (protocol v2), but
perhaps "fortunately" is the wrong way to say it. Perhaps a better way
of explaining it is that most code paths go through
fetch_refs_via_pack(), and for the ones that don't (bundle transport and
non-takeover transport helpers), we need to address them separately. But
in this case, we are not planning to support either, so we just check if
we have requested independent negotiation and if yes, report failure.

> I can understand "while interacting with the bundle transport, you
> cannot do independent negotiation, but there is nothing to negotiate
> with a static file that is a bundle anyway, so nothing is lost" as
> an explanation, though.
> 
> >  Documentation/technical/protocol-v2.txt |  8 +++
> >  builtin/fetch.c                         | 27 +++++++-
> >  fetch-pack.c                            | 89 +++++++++++++++++++++++--
> >  fetch-pack.h                            | 11 +++
> >  object.h                                |  2 +-
> >  t/t5701-git-serve.sh                    |  2 +-
> >  t/t5702-protocol-v2.sh                  | 89 +++++++++++++++++++++++++
> >  transport-helper.c                      | 10 +++
> >  transport.c                             | 30 +++++++--
> >  transport.h                             |  6 ++
> >  upload-pack.c                           | 18 +++--
> >  11 files changed, 275 insertions(+), 17 deletions(-)
> 
> It is a bit surprising that there isn't much code removed, as I
> expected that we'd be factoring out and reusing existing code used
> in negotiation for fetching into a new helper function (hence the
> existing codepath would lose a lot of code to be replaced by a call
> to a new helper function), but that is apparently not what is going
> on.

That's what I was trying to do (hence the earlier patches), but the main
thing I ran into is that a lot of the fetch code assumes that you're
fetching at least one ref, so I couldn't use a lot of it without more
code updating. Having said that, I may have missed more opportunities
for reuse.

> I'll have to revisit this step and the next step tomorrow.
> 
> Thanks.

Thanks for taking a look.

  reply	other threads:[~2021-04-09 16:38 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-09  1:09 [PATCH 0/6] Push negotiation Jonathan Tan
2021-04-09  1:09 ` [PATCH 1/6] fetch-pack: buffer object-format with other args Jonathan Tan
2021-04-09  4:49   ` Junio C Hamano
2021-04-09 16:24     ` Jonathan Tan
2021-04-09  1:09 ` [PATCH 2/6] fetch-pack: refactor process_acks() Jonathan Tan
2021-04-09  5:08   ` Junio C Hamano
2021-05-03 16:30   ` Derrick Stolee
2021-04-09  1:10 ` [PATCH 3/6] fetch-pack: refactor add_haves() Jonathan Tan
2021-04-09  5:20   ` Junio C Hamano
2021-04-09  1:10 ` [PATCH 4/6] fetch-pack: refactor command and capability write Jonathan Tan
2021-04-09  5:27   ` Junio C Hamano
2021-04-09  1:10 ` [PATCH 5/6] fetch: teach independent negotiation (no packfile) Jonathan Tan
2021-04-09  5:41   ` Junio C Hamano
2021-04-09 16:38     ` Jonathan Tan [this message]
2021-05-03 15:25   ` Derrick Stolee
2021-05-03 15:40     ` Derrick Stolee
2021-05-03 21:52     ` Jonathan Tan
2021-04-09  1:10 ` [PATCH 6/6] send-pack: support push negotiation Jonathan Tan
2021-05-03 15:35   ` Derrick Stolee
2021-05-03 22:02     ` Jonathan Tan
2021-05-04 17:26       ` Derrick Stolee
2021-04-30  5:42 ` [PATCH 0/6] Push negotiation Junio C Hamano
2021-04-30 17:33   ` Derrick Stolee
2021-05-04 21:15 ` [PATCH v2 0/5] " Jonathan Tan
2021-05-04 21:15   ` [PATCH v2 1/5] fetch-pack: refactor process_acks() Jonathan Tan
2021-05-04 21:15   ` [PATCH v2 2/5] fetch-pack: refactor add_haves() Jonathan Tan
2021-05-04 21:16   ` [PATCH v2 3/5] fetch-pack: refactor command and capability write Jonathan Tan
2021-05-04 21:16   ` [PATCH v2 4/5] fetch: teach independent negotiation (no packfile) Jonathan Tan
2021-05-05  1:53     ` Junio C Hamano
2021-05-05 16:42       ` Derrick Stolee
2021-05-06  2:12         ` Junio C Hamano
2021-05-05 16:44     ` Derrick Stolee
2021-05-04 21:16   ` [PATCH v2 5/5] send-pack: support push negotiation Jonathan Tan

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=20210409163835.2560428-1-jonathantanmy@google.com \
    --to=jonathantanmy@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --subject='Re: [PATCH 5/6] fetch: teach independent negotiation (no packfile)' \
    /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

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.version-control.git
	nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.version-control.git
	nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

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

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git