From: Jonathan Tan <jonathantanmy@google.com>
To: gitster@pobox.com
Cc: jonathantanmy@google.com, git@vger.kernel.org
Subject: Re: [RFC PATCH] push: perform negotiation before sending packfile
Date: Thu, 18 Feb 2021 15:02:48 -0800 [thread overview]
Message-ID: <20210218230248.1165266-1-jonathantanmy@google.com> (raw)
In-Reply-To: <xmqqwnv6gnuq.fsf@gitster.g>
> Jonathan Tan <jonathantanmy@google.com> writes:
>
> > The idea of adding negotiation to push has been floating around for a
> > while. Here's my implementation of my idea of reusing a lot of the fetch
> > mechanism to perform the negotiation.
>
> Finally? Yay!
Thanks.
> > The basic idea is that when a client pushes, the client will first
> > perform the negotiation steps that it normally does during a fetch,
> > except that it does not send any "want"s and it only uses the commits to
> > be pushed as negotiation tips (instead of all refs). Once the client has
> > received enough ACKs that all ancestral paths from all tips to the
> > original orphans are blocked by ACKed commits, it will proceed with the
> > push, using this information to determine the contents of the
> > to-be-pushed packfile. (This check is done by the server when doing a
> > user-triggered fetch.)
>
> So when pushing 'HEAD' to some ref, we say "I have HEAD^{commit},
> HEAD^^, HEAD^^^, ..." and they keep saying "never heard of it" for
> each of them until they find "ah, I know that one" with an ACK, at
> which point we can stop traversing our side of the history behind
> that acked commit (because everything behind it is common between
> us). And that way, we know what we do not have to send (i.e. what
> we should use as the negative ends of "rev-list --objects A..B";
> their ACK lets us discover "A").
Yes, that's right.
> Do we take advantage of the ref advertisement the other side
> perform, or is this v2 only and we even skip ls-refs?
My plan is to make it v2-only, but I don't think that there are
technical limitations in adding it to v0. I'm planning to skip ls-refs
(the current proof-of-concept code still calls ls-refs but doesn't use
its results). If we need to take advantage of the ref advertisement, we
could just use push's one.
> What do you mean by an "orphan", though? Except for that part, I
> think what you wrote the above makes quite a lot of sense.
By "orphan" I meant the commits that don't have any parents - so, the
root commits.
> When we have an "--allow-unrelated-histories" merge with a history
> they've never heard of, we'd end up digging down to the root of the
> unrelated side history with "have/nack" exchange. On the fetch
> side, we have "give up with too many nack" band-aid. Do we inherit
> the same from the fetch side?
Yes. (But like fetch, this "in vain" check triggers only after the first
ACK.)
> > - Do we need statistics in the commit message to show the performance
> > gains?
>
> Not until we see the thing fully working, I would say.
OK.
prev parent reply other threads:[~2021-02-18 23:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 1:21 [RFC PATCH] push: perform negotiation before sending packfile Jonathan Tan
2021-02-18 1:34 ` Junio C Hamano
2021-02-18 20:25 ` Junio C Hamano
2021-02-18 21:33 ` Junio C Hamano
2021-02-19 0:42 ` Jonathan Tan
2021-02-20 3:25 ` Junio C Hamano
2021-02-22 20:01 ` Jonathan Tan
2021-02-22 21:32 ` Junio C Hamano
2021-02-18 23:02 ` Jonathan Tan [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=20210218230248.1165266-1-jonathantanmy@google.com \
--to=jonathantanmy@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public 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).