1381608 - Initial push-to-review support

Status: RESOLVED WONTFIX

(Conduit :: General, enhancement)

Description

[Mark Côté [:mcote]]

Although Differential works well with its command-line tool, Arcanist, there are some advantages to using a review repository: convenience ("push" and "pull" commands being already widely understood) and clarity (the commits hold all the necessary data for them to be autolanded).

This is a tracking bug for a first service that we will build on.  The first incarnation will be "squash on landing", similar to GitHub's traditional approach, which fixes are appended as individual commits which are all folded together into one commit before landing.  This is a straightforward method that will introduce the basic building blocks (a new staging repo, landing from the staging repo, etc.).  Only public commits will be supported initially, though the system will be designed such that we can subsequently support confidential commits.

Comment 1

[Mark Côté [:mcote]]

Update: due to a variety of concerns, including security and support for multiple VCSs, we may change tack on this and write some convenience scripts that either use or replace Arcanist to better submit and track series of commits.  More to come in the next couple months.

Comment 2

[Jan Henning [:JanH]]

Luckily arc caters for the most important part of my workflow by supporting Mercurial bookmarks (the arc:bookmark commit range rule), but one advantage of the current implementation is that for "hg push review"
- you relatively flexible in deciding which revisions to submit
- more importantly, you don't have to physically check out the revision you want to submit into the working directory

The latter is nice when dealing with stacked commits if they need to go into different reviews and you want to submit them all at the end after you've reached a consistent state and don't additional need changes in previous commits for the time being.
Having to switch the working directory for each review request then is an - albeit small - extra step and more annoyingly marks all affected files as dirty again as far as the build system is concerned.

Comment 3

[Gregory Szorc [:gps]]

https://www.mercurial-scm.org/repo/hg/file/@/contrib/phabricator.py is the Mercurial extension that Mercurial itself is using to send and receive commits to Phabricator. Although the last I heard we may be going with bundle-based uploading (!!!), so this script may not be of much value except possibly as inspiration for code that we need to deploy on the server.

Comment 4

[Tom Prince [:tomprince]]

I've been successfully using  the mercurial extension along with https://phabricator.services.mozilla.com/D345 to submit review to phabricator.

Comment 5

[Gregory Szorc [:gps]]

I've successfully used the Mercurial extension for submitting to Mozilla's Phabricator as well. Needed features off the top of my head:

* Ability to associate the Differential items with a Bugzilla bug.
* Support for configuring multiple Phabricator credentials depending on the Phabricator endpoint (you probably want the credentials defined in a central hgrc but the Phabricator instance to be per-repo).
* Move to core (right now it isn't distributed/installed with Mercurial).

Comment 6

[Tom Prince [:tomprince]]

> * Ability to associate the Differential items with a Bugzilla bug.

https://phabricator.services.mozilla.com/D345

> * Support for configuring multiple Phabricator credentials depending on the Phabricator endpoint (you probably want the credentials defined in a central hgrc but the Phabricator instance to be per-repo).

https://phab.mercurial-scm.org/D1919

Comment 7

[Mark Côté [:mcote]]

Our official solution is moz-phab.  It's a bit different from pure push/repo support so I'll WONTFIX this.