in T6722#197239 I had the same problem with "land revision from Web UI" :)

I think the general shape of this is:

• Use git hash-object to build an empty commit pointing at the empty tree.
• Squash or merge onto it.

This gives us a commit with the correct tree, and allows us to execute all the normal squash/merge code (we have a legitimate "into" target).

Then:

• If we squashed, use git hash-object to write a new commit which is identical to the result, but has no parent.
• If we merged, use git hash-object to write a new commit which is identical to the merge commit, but has only one parent.

Finally, use the commit which came out of that step as the final outcome of the process.

This means we end up with a small amount of unique code which only runs occasionally during this workflow, but most of the code can be shared: we don't have to write completely unique "if empty" merge strategies.