Tracking: adopt commit/PR streaming end-to-end in downstream consumers

[ognis1205]

Is there an existing issue or pull request for this?

• I have searched the existing issues and pull requests

Feature description

The remote layer was recently refactored to expose commits and pull requests as streams (PR #1272). While this clears the way for smarter request strategies and performance improvements, the downstream code
still eagerly collects these streams into Vecs and processes them in a non-streaming fashion.

As a result, the current implementation does not yet benefit from:

• early exits
• reduced API requests

In other words, the streaming abstraction is not yet reflected end-to-end.

Desired solution

Adopt streaming semantics throughout downstream consumers so that commit and pull request data can be processed incrementally instead of being fully materialized upfront.

This issue is intended as a tracking issue, and the work can be implemented incrementally across multiple follow-up PRs.

Alternatives considered

• Keeping the current eager collection approach and relying on pagination limits or higher rate limits
• mplementing ad-hoc early-exit logic on top of fully collected result sets

These alternatives do not fully realize the benefits enabled by the stream-based remote refactor.

Additional context

Related PR: #1272

[orhun]

One significant downstream consumer is @release-plz. We could potentially look at what they are doing and start from there.

[ognis1205]

One significant downstream consumer is @release-plz. We could potentially look at what they are doing and start from there.

Thanks for the pointer. That makes sense.

In my case, the downstream usage I had in mind is currently contained within git-cliff-core itself, specifically around these areas:

• git-cliff/git-cliff-core/src/changelog.rs

  Lines 262 to 275 in 0b6af12

  	let data = tokio::runtime::Builder::new_multi_thread()
  	.enable_all()
  	.build()?
  	.block_on(async {
  	let (commits, pull_requests) = tokio::try_join!(
  	github_client.get_commits(ref_name),
  	github_client.get_pull_requests(ref_name),
  	)?;
  	log::debug!("Number of GitHub commits: {}", commits.len());
  	log::debug!("Number of GitHub pull requests: {}", pull_requests.len());
  	Ok((commits, pull_requests))
  	});
  	log::info!("{}", github::FINISHED_FETCHING_MSG);
  	data

• git-cliff/git-cliff-core/src/remote/mod.rs

  Lines 310 to 314 in 0b6af12

  	pub fn $fn(
  	&mut self,
  	mut commits: Vec<Box<dyn RemoteCommit>>,
  	pull_requests: Vec<Box<dyn RemotePullRequest>>,
  	) -> Result<()> {

That said, from my personal perspective, I think there's also an option to gradually move toward a stream-based API more broadly, for example, keeping the existing non-stream-based APIs for now but marking them as #[deprecated], and transitioning incrementally.

This would obviously need some discussion and agreement, but I wanted to put it on the table as a possible direction.