On Wed, Apr 1, 2015 at 2:58 AM, Junio C Hamano <gits...@pobox.com> wrote:
> This is a follow-up on $gmane/264553, which is a continuation of
> $gmane/264000, but instead of giving two required readings to
> readers, I'll start with reproduction of the two, and add a few more
> things the current protocol lacks that I would want to see in the
> updated protocol.
I think the important thing to get v2 started is making sure we do not
need v3 to get rid of any of these limitations. In other words v2
should be extensible enough to implement them later. I'm looking from
this perspective.
> The current protocol has the following problems that limit us:
>
> - It is not easy to make it resumable, because we recompute every
> time. This is especially problematic for the initial fetch aka
> "clone" as we will be talking about a large transfer. Redirection
> to a bundle hosted on CDN might be something we could do
> transparently.
Sending multiple packs or some redirection instructions could be done
even with v1. The only recompute part that is unavoidable in v1 is ref
advertisement, which I think is solved.
> - The protocol extension has a fairly low length limit.
One pkt-line per protocol extension should do it.
> - Because the protocol exchange starts by the server side
> advertising all its refs, even when the fetcher is interested in
> a single ref, the initial overhead is nontrivial, especially when
> you are doing a small incremental update. The worst case is an
> auto-builder that polls every five minutes, even when there is no
> new commits to be fetched.
One of the reason v2 is started, should be ok with current v2 design.
> - Because we recompute every time, taking into account of what the
> fetcher has, in addition to what the fetcher obtained earlier
> from us in order to reduce the transferred bytes, the payload for
> incremental updates become tailor-made for each fetch and cannot
> be easily reused.
Well, we reuse at a lower level, pack-objects would try to copy
existing deltas instead of making new ones. We can cache new deltas in
hope that they may be useful for the next fetch. But that has nothing
to do with the protocol..
> - The semantics of the side-bands are unclear.
>
> - Is band #2 meant only for progress output (I think the current
> protocol handlers assume that and unconditionally squelch it
> under --quiet)? Do we rather want a dedicated "progress" and
> "error message" sidebands instead?
>
> - Is band #2 meant for human consumption, or do we expect the
> other end to interpret and act on it? If the former, would it
> make sense to send locale information from the client side and
> ask the server side to produce its output with _("message")?
The interpretation of side-band could be changed by introducing a new
extension, couldn't it?
> - The semantics of packet_flush() is suboptimal, and this
> shortcoming seeps through to the protocol mapped to the
> smart-HTTP transport.
>
> ...
I don't have an answer to this one. So the reaction is, if it is not
"broken" (in pratice, not in theory), don't touch it. I know I'm
burying my head in the sand..
> - The fetch-pack direction does the common-parent discovery but the
> push-pack direction does not. This is OK for the normal
> fast-forward push, in which case we will see a known commit on
> the tip of the branch we are pushing into, but makes forced push
> inefficient.
Introducing the ref exchange in push-pack could be done in an
extension too, I think.
> - The existing common-parent discovery done on the fetch-pack side
> enumerates commits contiguously traversing the history to the
> past. We might want to go exponential or Fibonacci to quickly
> find an ancient common commit and bisect the history from there
> (or it might turn out not to be worth it).
Hm.. i'm wondering if we can already do this with v1 if we have enough
man power.
> - We may want to revamp the builtin/receive-pack.c::report() that
> reports the final result of a push back to the pusher to tell the
> exact object name that sits at the updated tips of refs, not just
> refnames. It will allow the server side to accept a push of
> commit X to a branch, do some "magic" on X (e.g. rebase it on top
> of the current tip, merge it with the current tip, or let a hook
> to rewrite the commit in any way it deems appropriate) and put
> the resulting commit Y at the tip of the branch. Without such a
> revamp, it is currently not possible to sensibly allow the server
> side to rewrite what got pushed.
Sounds more coding than changing the protocol, which should be
possible with another extension.
> - If we were to start allowing the receiver side to rewrite pushed
> commits, the updated send-pack protocol must be able to send the
> new objects created by that "magic" back to the pusher. The
> current protocol does not allow the receive-pack to send packdata
> back to send-pack.
Is it cleaner to just initiate another fetch to get that pack? Maybe
race conditions make it not a good option?
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
