In particular, T182 discusses a desired "chain of custody" workflow where the merge/promote flow happens on the server.

When configured, the behavior of arc land would become approximately:

• Click the "Land Revision" button in the web UI (not really, but do the same thing via the API).
• Delete the local branch.

If the merge/promote fails, users would need to recover the local branch to fix the problem. arc patch D1234 is a reasonable way to do this, and can be made much faster and more reliable if it learns to examine the working copy for the expected commit hash.

A possibly-user-friendlier alternative is to keep the branch (showing, e.g., "Landing" as a status in arc branch) and let some future arc cleanup (T3277) remove it. This may make more sense as a default, but letting arc patch cheaply recover in-flight branches would benefit users who delete these branches (on purpose or otherwise).

In our setup (as an open source project) we often get differentials created with base commits which do not exist in upstream. As a result using arc patch often fails, even worse, in a non-recoverable way as --reject is passed to git apply. In a patch fails to cleanly apply it is hard to continue the work-flow and manually correct the merge conflicts.

On the other hand, almost all of our users push their commits to the staging repo.
A more robust solution would perhaps be to first look in the staging repo and attempt to cherry-pick the relevant commit. This has the advantages of firstly preserving proper author information and secondly being more recoverable in the case of merge conflicts.

Just want to add a note that with git lfs managed files, arc patch won't work unless one fetch the ref tag and then the lfs blobs from the staging server first. See https://discourse.phabricator-community.org/t/arc-patch-fails-with-git-lfs-files/2447/3