git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Brandon Williams <bmwill@google.com>
Cc: Derrick Stolee <stolee@gmail.com>,
	Stefan Beller <sbeller@google.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [RFC] push: add documentation on push v2
Date: Wed, 18 Jul 2018 19:19:53 +0200	[thread overview]
Message-ID: <CACsJy8DaeUWo1qmgyxZ_9kuKLyRP+m1kgNGkoj6LtOMTknvEYQ@mail.gmail.com> (raw)
In-Reply-To: <20180718171127.GB17137@google.com>

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
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
also talk about configuring hooks with config file. These should make
it possible to deal with change-id generation with minimum manual
intervention.
-- 
Duy

  reply	other threads:[~2018-07-18 17:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-17 21:09 [RFC] push: add documentation on push v2 Brandon Williams
2018-07-17 23:25 ` Stefan Beller
2018-07-18 13:31   ` Derrick Stolee
2018-07-18 16:56     ` Stefan Beller
2018-07-18 17:15       ` Brandon Williams
2018-07-20 13:12         ` Jeff Hostetler
2018-07-24 19:00           ` Brandon Williams
2018-07-18 17:11     ` Brandon Williams
2018-07-18 17:19       ` Duy Nguyen [this message]
2018-07-18 17:46         ` Brandon Williams
2018-07-18 17:57           ` Duy Nguyen
2018-07-18 17:08   ` Brandon Williams
2018-07-18 18:07     ` Stefan Beller
2018-07-18 18:17       ` Duy Nguyen
2018-07-18 18:21       ` Brandon Williams
2018-07-24 19:28 ` Brandon Williams
2018-07-25 15:15   ` Duy Nguyen
2018-07-25 17:46     ` Brandon Williams
2018-08-02 15:17       ` Duy Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACsJy8DaeUWo1qmgyxZ_9kuKLyRP+m1kgNGkoj6LtOMTknvEYQ@mail.gmail.com \
    --to=pclouds@gmail.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=sbeller@google.com \
    --cc=stolee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).