danobi
prr get, submit etc. support for '/pull/' within path?
👋🏻 firstly, thank you very much for making prr available for others to enjoy, excellent tooling!
Currently prr expects a short path format of <org|username>/<repo>/<pr-number>, e.g., prr get danobi/prr/24, prr submit danobi/prr/24 etc.
However, the URL path you'd typically expect to find on GitHub (after the domain) is danobi/prr/pull/24. It would be great if prr could transparently handle either form with or without /pull/ in between the repo and number.
Similarly I notice that prr does actually also accept and handle a fully qualified URL as well (i.e., prr get https://github.com/danobi/prr/pull/24), but only if it is a GitHub public URL. If you're using it against GitHub Enterprise (via url = "https://github.example.com/api/v3/) then it only supports the short ref style (which was why I was keen for the /pull/ support.)
👋🏻 firstly, thank you very much for making prr available for others to enjoy, excellent tooling!
Thanks! Glad you like it.
Currently prr expects a short path format of
<org|username>/<repo>/<pr-number>, e.g.,prr get danobi/prr/24,prr submit danobi/prr/24etc.However, the URL path you'd typically expect to find on GitHub (after the domain) is danobi/prr/pull/24. It would be great if prr could transparently handle either form with or without
/pull/in between the repo and number.Similarly I notice that prr does actually also accept and handle a fully qualified URL as well (i.e.,
prr get https://github.com/danobi/prr/pull/24), but only if it is a GitHub public URL. If you're using it against GitHub Enterprise (viaurl = "https://github.example.com/api/v3/) then it only supports the short ref style (which was why I was keen for the /pull/ support.)
Thanks for the report. And yeah, this makes sense to me. Would be good to support as many use cases as possible, as it's a relatively straightforward parsing problem. The current regex is getting pretty crazy though, so maybe it's time to something a little less clever.
