Make 'arc land' working on different machine

Hi,

when working on multiple machines it may happen that a review request
only exists on one machine A and in the staging area, but not in the upstream repository.

So when working on machine B and you try to land a review that was just accepted, this does not work:

Example:

$ arc land D72
Branch "D72" does not exist in the local working copy.

To fix this I do normally the following:

$ arc patch D72

this gives you the branch ‘arcpatch-D72’.

Now you have the changes but arc land D72 will still fail, because of the wrong branch name.
Then I simply create the expected branch name using git branch D72.
Now arc land D72 succeeds.

It would be nice if “arc” could streamline this process to “just work” even if the branch does not exist yet on the local machine. As you can see, technically it is possible, just not with a single “arc land” command.

I know, another workaround is pushing the review request to a personal feature branch in the upstream repo before it was accepted, but sometimes you just forget this. Making “arc land” working as I proposed would be a huge benefit IMO.

This could also be useful for automatic landing, e.g. after passing all CI builds.

Cheers,
Gerhard

arc land takes a branch name, not an object/revision name, so I expect arc patch D72 followed by arc land arcpatch-D72 (use the branch name, not the revision name) should work. This is approximately the same overall workflow, but a little easier than renaming the branch.

In the future, I intend to make arc land D123 mean “(prompt the user, and then) patch and land D123 and all open, unlanded dependencies of D123” but this is some ways away (see also: https://secure.phabricator.com/T3875).

Making “arc land” working as I proposed would be a huge benefit IMO.

There’s limited customer interest in this today, so it isn’t near the top of the priority list.

This could also be useful for automatic landing, e.g. after passing all CI builds.

(Once built, this will operate through the “Land Revision” flow on the server side, so improving the behavior of arc land isn’t a step toward it.)

This is approximately the same overall workflow, but a little easier than renaming the branch.

thx, that’s a good tip

Once built, this will operate through the “Land Revision” flow on the server side, so improving the behavior of arc land isn’t a step toward it.

Beside its prototype state “This feature is a prototype and has substantial limitations.” this also has some architectural limitations IMO. Probably you assume that phabricator is hosting the upstream Git repo. This is not the case for me, where phabricator only has a read-only mirror and a writable staging area. So the server could never push to upstream repo, because it doesn’t have the required SSH private key.
On the other side I have the SSH key (Yubikey) and can execute arc land. Also, our CI system has an SSH key which I could configure to get write permissions (currently it’s read only too).

I don’t know a way to give phabricator an “SSH private key” for the Server side Landing feature. Is this possible or do you plan such a feature? This would be useful too.

Probably you assume that phabricator is hosting the upstream Git repo.

This feature doesn’t assume that today, but may in the future. Currently, I’m not aware of any customers who are interested in improvements to “Land Revision” but do not host their repositories in Phabricator. If you don’t use Phabricator as a repository host, you should expect that some features won’t work (for example, “Commit Hook” Herald rules can’t work if Phabricator doesn’t control writes).

Conceivably, you could use Webhooks + some script glue + arc land to accomplish the same goal if you can not host your repositories on Phabricator, but it’s unlikely that Phabricator will add explicit support for running arc patch + arc land on host it doesn’t control unless this workflow becomes very important for a large number of customers.

I don’t know a way to give phabricator an “SSH private key” for the Server side Landing feature.

Currently, it just runs bare ssh via git push on the host, so putting the key in ~/.ssh/id_rsa (or similar) of the user account that Phabricator connects to the host machine as will work. If you can connect to the “land” host and run “git push” successfully, Phabricator will also be able to.

1 Like