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.

If there were a simple to use continue or start-from mechanism documented this would allow a work-around.

@GadgetSteve Possibly, but I'm not sure how gh would display pagination info in its UI. Exposing lower-level pagination info doesn't seem like a great fit for gh right now, and if you need a way to continue paginating based on a previously fetched set, perhaps you should drop down to the GitHub API level manually where you have access to page parameter in REST API or cursor pagination in the GraphQL API?

query ($endCursor: String) {
	repository(owner: "cli", name: "cli") {
		issues(states: OPEN, first: 100, after: $endCursor) {
			nodes {
				number
				title
			}
			pageInfo {
				hasNextPage
				endCursor
			}
		}
	}
}

Since API returns a flag (hasNextPage) to say that there is more data including this in the response along with the endCursor and adding a --startfrom option could potentially allow a last line to be added to the output text something along the lines of:

More entries to list if needed use --startfrom=<endCursor>

The json response could include a last entries with fields of:
'NextPage:endCursor`

could potentially allow a last line to be added to the output text something along the lines of:

That sounds good in theory, but how would be output this line in machine-readable mode and expect that current scripts won't trip up over it thinking it's an issue record?

The json response could include a last entries with fields

That also sounds good in theory, but the top-level data type of our --json response is a JSON array. We can only add more records to the array but not extra fields without changing the JSON array to a JSON object, which would break backwards-compatibility with JSON consumers.