On 07/18, Duy Nguyen wrote: > On Wed, Jul 18, 2018 at 7:13 PM Brandon Williams <bmwill@xxxxxxxxxx> 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 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. > 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. > also talk about configuring hooks with config file. These should make > it possible to deal with change-id generation with minimum manual > intervention. -- Brandon Williams
