This patch adds an alias for “patch”: “pr”.

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 might be controversial, yes, but I think have to start the discussion at some point, so why not do it now?

I am open to your thoughts!

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.