Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

prr get, submit etc. support for '/pull/' within path? #51

Open
dnwe opened this issue Jan 11, 2024 · 1 comment
Open

prr get, submit etc. support for '/pull/' within path? #51

dnwe opened this issue Jan 11, 2024 · 1 comment

Comments

@dnwe
Copy link

dnwe commented Jan 11, 2024

👋🏻 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.)

@danobi
Copy link
Owner

danobi commented Jan 11, 2024

👋🏻 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/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.)

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants