Prior to changes in T13546, when using arc land --hold with mercurial the resulting state had both merged the branch and pruned the merged branch, effectively doing everything except pushing the squashed commit upstream. This behavior was different from git, where git would not prune the merged branch in addition to not pushing the squashed commit. The behavior used with git was the intended behavior, and in this sense mercurial's behavior was abnormal. Changes from T13546 brought mercurial's behavior to match git's.
There are a few use cases where pruning the original branch while using --hold has been desirable, though admittedly these are likely very specific to our internal processes. I've discussed with colleagues to understand more use cases than the one I was originally familiar with, and it turns out several have refused to upgrade arcanist because of this specific change in behavior. The use cases we have are:
- When making fixes in older versions of a product, we require all changesets exist in the repos for newer versions before allowing it to be pushed to the older version. In this case, using plain arc land from the older version will fail due to the push being rejected. Previously we used arc land --hold, jump to the newer versions, pull & merge the new commit to land, then push up that commit in all versions. Now it requires some additional handling to clean up the merged branch, as well as requiring more-specific pulls between repositories as by default mercurial will pull all commits.
- There are some products which require re-computing new generated code based on the new state of the codebase. Using arc land will pull in new changesets and rebase the work to be landed on top. Previously arc land --hold was used to get everything setup to go, a task is run to compute new generated code, then ammended to the commit to push. This now requires additional cleanup of the original branch.
- I suspect there might be changes that could be made to the develepment process (e.g. always pull & rebase, generate code, update diff, then land) or accomplish this with CI/CD however I do not work on this product and am not involved in their development processes.
- Some colleagues really want to inspect everything before pushing things upstream. Also here the conflict is in having to clean up the old branches.
This change adds a new prompt arc.land.prune-after-hold which appears when using --hold and allows the user to choose whether the merged branch should be pruned.
As part of this I updated ArcanistPrompt to allow specifying that the prompt does not abort the workflow if the user responds n, and the allowing the user's response to be retrieved. This is because the response to this new prompt changes the behavior of arc land instead of stopping the workflow.