@aryanbhosale : Thank you for finding ways to contribute to the GitHub CLI! However, the direction of the linked issue is very different than the changes you propose:

Hi, thank you for the feature request, but it is by design that you must always specify the limit for fetching issues, pull request, repositories, or basically any unbounded set of data on GitHub.

Having a "no limit" setting would be convenient but would also be tricky if people started using it in their workflows or scripts without giving it a second thought. For example, fetching all issues without limit from this repository would likely complete in under a minute, but fetching all issues from some other repositories I belong to could potentially take many minutes. For example, the VS Code repository currently has 124,827 issues. Since we can only ever fetch 100 issues per request, we would need 1,249 sequential requests to fetch all of these issues. Now, if you take into account the overhead of making a single API request to GitHub, then multiply that to a thousand, then also consider rate limit restrictions, you can start to understand why unbounded fetching of data over the network is rarely a good idea.

So, if you need to fetch all issues from a large repository, specify a large --limit number to encompass all data that you are interested in. Specifying a large number as a limit forces you to consider what would happen if there actually were enough records to fill that limit.

However, we could document this restriction better, I agree! I'm going to re-classify this as a documentation issue.

As such, I'm closing this PR until we discuss new acceptance criteria within the issue behind this behavior.

Thank you @andyfeller for you feedback