We currently have a workflow where code is never landed to origin/master directly; instead, an API call is made which returns a remote and branch name to push to, and the proposed code to merge is pushed there. The remote host ensures that tests pass, then merges and pushes the code to origin/master. Subsequent fetches from the client then pick up the newly-added change.
This is currently implemented as a custom workflow, which duplicates a fair amount of code of ArcanistLandWorkflow; as that is marked final, and its core properties are mostly marked private, there is currently not clean way to re-use its code.
The newly-added ArcanistLandEngine abstraction is not marked final, and provides nearly enough rope to implement this cleanly. By subclassing ArcanistGitLandEngine, and overriding pushChange to push the change to an alternate remote, the desired behavior can be implemented in a minimally invasive way. This seems preferable to the bigger change of allowing the the value of TargetRemote to be a URL, instead of a remote name -- in this workflow, the remote that is pushed to is never fetched from, only pushed to, so it is never explicitly added by name. Changing ArcanistGitLandEngine to support URL-only remotes seems like a larger undertaking -- and in some ways, the remote really is origin, just not for the push action.
Git itself supports this as a concept, via the remote.pushdefault configuration; though that itself doesn't provide quite enough flexibility, as the branch name to push into needs to be be provided by an API call.
The difficulty of implementing this cleanly is that the underlying ArcanistLandEngine of arc land is not configurable, and some key behavior is locked away un the un-inspectable and un-subclassable arc land. Do you have suggestions for how to implement this workflow cleanly?