In git, a "pull request" (short "pr") is a request to merge a branch. GitHub has coined this term, but git-request-pull is a thing as well (and apparently has been since 2005):

https://github.com/git/git/blob/2cc71917514657b93014134350864f4849edfc83/git-request-pull.sh#L2

Users new to radicle might be confused by the term "patch" used where they expect "pull request" - or short "pr". Thus, alias the subcommand "patch" to "pr".

I think this is a fair criticism, especially the new user coming to Radicle. On the other hand, I could argue that we would want to break their biases. If we call it a pull request, then they may expect the same, or similar semantics of a GitHub pull request.

We opted to call them patches to be more similar to email patch flow. You git-format-patch to get a list of patch files, that you submit via email. In Radicle, you get the patch range, head to base.

I think both naming conventions are valid. However, I would say you're requesting to patch, not to pull in Radicle. The patch has landed in your local disk already; no need to pull.

We opted to call them patches to be more similar to email patch flow.

I see. In this case, though, a "patch" in radicle is not always a single commit ("patch"), right? So, it would rather be something like "open a patchset" or "review a patchset" or "show a patchset", rather than "show a patch" (which semantically would mean a single commit).

(Just thinking out loud here of course).

You git-format-patch to get a list of patch files, that you submit via email.

Yeah, as a "set" or "list" of patches ;-)

The patch has landed in your local disk already; no need to pull.

Right, you'd request to "merge" that branch that's already there, so it would be a "merge request" ;-)