Make `arc patch` try the local working copy and staging areas
Open, NormalPublic

Description

In modern (and future/planned) configurations, arc patch has two high-quality sources for patches that it does not currently examine:

  • arc patch can look for the commit hash already in the working copy. This would, e.g., allow quick, reliable recovery of branches removed by arc land.
  • If staging areas are configured, arc patch can attempt to git fetch the changes from the staging area. When it works, this is more reliable and complete (e.g., history-preserving) than shipping bundles around. While arc patch should probably also become history-preserving eventually, this is a much larger change than trying staging areas before falling back to the current workflow.

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).

avivey added a subscriber: avivey.Jun 7 2016, 5:37 PM
epriestley moved this task from Backlog to arc patch on the Arcanist board.Jul 8 2016, 2:49 PM
joshma added a subscriber: joshma.Jul 19 2016, 9:36 PM
mpickering added a subscriber: bgamari.

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.