Page MenuHomePhabricator

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.

Event Timeline

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.