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

[Brandon Williams <bmwill@google.com>]

On 07/18, Derrick Stolee wrote:
> On 7/17/2018 7:25 PM, Stefan Beller wrote:
> > On Tue, Jul 17, 2018 at 2:09 PM Brandon Williams <bmwill@google.com> 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.
> > It would be nice to know which things you want to improve.
> 
> Hopefully we can also get others to chime in with things they don't like
> about the existing protocol. What pain points exist, and what can we do to
> improve at the transport layer before considering new functionality?
> 
> > >   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).
> > Well Gerrit is our main motivation, but this allows for other workflows as well.
> > For example Facebook uses hg internally and they have a
> > "rebase-on-the-server-after-push" workflow IIRC as pushing to a single repo
> > brings up quite some contention. The protocol outlined below would allow
> > for such a workflow as well? (This might be an easier sell to the Git
> > community as most are not quite familiar with Gerrit)
> 
> I'm also curious how this "change commits on push" would be helpful to other
> scenarios.
> 
> Since I'm not familiar with Gerrit: what is preventing you from having a
> commit hook that inserts (or requests) a Change-Id when not present? How can
> the server identify the Change-Id automatically when it isn't present?

Right now all Gerrit users have a commit hook installed which inserts
the Change-Id.  The issue is that if you push to gerrit and you don't
have Change-ids, the push fails and you're prompted to blindly run a
command to install the commit-hook.  So if we could just have the server
handle this completely then the users of gerrit wouldn't ever need to
have a hook installed in the first place.


-- 
Brandon Williams