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?