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

[Duy Nguyen <pclouds@gmail.com>]

On Wed, Jul 18, 2018 at 7:46 PM Brandon Williams <bmwill@google.com> wrote:
>
> On 07/18, Duy Nguyen wrote:
> > On Wed, Jul 18, 2018 at 7:13 PM Brandon Williams <bmwill@google.com> wrote:
> > > > > > 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.
> >
> > I don't trust the server side to rewrite commits for me. And this is
>
> That's a fair point.  Though I think there are a number of projects
> where this would be very beneficial for contributors. The main reason
> for wanting a feature like this is to make the UX easier for Gerrit
> users (Having server insert change ids as well as potentially getting
> rid of the weird HEAD:refs/for/master syntax you need to push for
> review).  Also, if you don't control a server yourself, then who ever
> controls it can do what it wants with the objects/ref-updates you send
> them.  Of course even if they rewrite history that doesn't mean your
> local copy needs to mimic those changes if you don't want them too.  So
> even if we move forward with a design like this, there would need to be
> some config option to actually accept and apply the changes a server
> makes and sends back to you.

This is the main pain point for me. I almost wrote a follow mail along
the line of "having said that, if we can be transparent what the
changes are or have some protection  at client side against
"dangerous" changes like tree/blob/commit-header replacement then it's
probably ok".

There's also other things like signing which will not work well with
remote updates like this. I guess you can cross it out as "not
supported" after consideration though.

> This RFC doesn't actually address those
> sorts of UX implications because I expect those are things which can be
> added and tweaked at some point in the future.  I'm just trying to build
> the foundation for such changes.

Speaking of UX, gerrit and this server-side ref-update. My experience
with average gerrit users is they tend to stick to a very basic set of
commands and if this is not handled well, you just replace the
one-time pain of installing hooks with a new one that happens much
more often, potentially more confusing too.

> > basically rewriting history (e.g. I can push multiple commits to
> > gerrit if I remember correctly; if they all don't have change-id, then
> > the history must be rewritten for change-id to be inserted). Don't we
> > already have "plans" to push config from server to client? There's
>
> I know there has been talk about this, but I don't know any of any
> current proposals or work being done in this area.

As far as I know, nobody has worked on it. You're welcome to start of course ;-)
-- 
Duy