Re: [PATCH] protocol upload-pack-v2

> 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.

> 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.

>  - 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.

>  - 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.

>  - 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 semantics of packet_flush() is suboptimal, and this
>    shortcoming seeps through to the protocol mapped to the
>    smart-HTTP transport.
>
>    ...

>  - 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.

>  - 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).

>  - 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.

>  - 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.