Re: [RFC] push: add documentation on push v2

From: Duy Nguyen <pclouds@gmail.com>
Date: Jul 25, 2018, 15:15 UTC
Message-ID: <CACsJy8C9z14GsxfyPm_pDuGwAQqm6Cdi2dO3bsqiYDE0scVbkQ@mail.gmail.com>
In-Reply-To: <20180724192811.GC225275@google.com>

On Tue, Jul 24, 2018 at 9:29 PM Brandon Williams <bmwill@google.com> wrote:

Show 33 quoted lines

>
> On 07/17, Brandon Williams wrote:
> > Signed-off-by: Brandon Williams <bmwill@google.com>
> > ---
> >
> > Since introducing protocol v2 and enabling fetch I've been thinking
> > about what its inverse 'push' would look like.  After talking with a
> > number of people I have a longish list of things that could be done to
> > improve push and I think I've been able to distill the core features we
> > want in push v2.  Thankfully (due to the capability system) most of the
> > other features/improvements can be added later with ease.
> >
> > What I've got now is a rough design for a more flexible push, more
> > flexible because it allows for the server to do what it wants with the
> > refs that are pushed and has the ability to communicate back what was
> > done to the client.  The main motivation for this is to work around
> > issues when working with Gerrit and other code-review systems where you
> > need to have Change-Ids in the commit messages (now the server can just
> > insert them for you and send back new commits) and you need to push to
> > magic refs to get around various limitations (now a Gerrit server should
> > be able to communicate that pushing to 'master' doesn't update master
> > but instead creates a refs/changes/<id> ref).
> >
> > Before actually moving to write any code I'm hoping to get some feedback
> > on if we think this is an acceptable base design for push (other
> > features like atomic-push, signed-push, etc can be added as
> > capabilities), so any comments are appreciated.
> >
> >  Documentation/technical/protocol-v2.txt | 76 +++++++++++++++++++++++++
> >  1 file changed, 76 insertions(+)
>
> Pinging this thread again to hopefully reach some more people for
> commentary.

Could you send a v2 that covers all the push features in pack version 1? I see some are discussed but it's probably good to summarize in this document too.

A few other comments

If I remember correctly, we always update the remote refs locally after a push, assuming that the next 'fetch' will do the same anyway. This is not true for special refs (like those from gerrit). Looking from this I don't think it can say "yes we have received your pack and stored it "somewhere" but there's no visible ref created for it" so that we can skip the local remote ref update?

Is it simpler to tell a push client at the end that "yes there's new stuff now on the server, do another fetch", sort of like HTTP redirect, then the client can switch to fetch protocol to get the new stuff that the server has created (e.g. rebase stuff)? I assume we could reuse the same connection for both push and fetch if needed. This way both fetch and push send packs in just one direction.

-- 
Duy