Two unrelated doc/naming nits, grouped since neither has a functional fix and both are low priority.
GitHubCloneManager's javadoc claims parallel cloning; cloneAll() is sequential. Plain for loop over namespaceRepos.entrySet(). Misleading, and a real startup-latency issue past a handful of namespaces.
GitHubWriteNotSupportedException is also thrown from read-path/admin-listing methods in GitHubUserAccessStore where the failure isn't "you tried to write" but "this operation has no meaning in GitHub mode". Message text is accurate at each site — cosmetic, not a correctness bug.
Fix: for 1, fix the javadoc or make cloneAll() genuinely parallel (reuse the ManagedExecutor GitHubStartupInitializer already has). For 2, rename to something more general (GitHubOperationNotSupportedException) or add a second exception type for the non-write cases.
(Surfaced during #3066's review.)
Two unrelated doc/naming nits, grouped since neither has a functional fix and both are low priority.
GitHubCloneManager's javadoc claims parallel cloning;cloneAll()is sequential. Plainforloop overnamespaceRepos.entrySet(). Misleading, and a real startup-latency issue past a handful of namespaces.GitHubWriteNotSupportedExceptionis also thrown from read-path/admin-listing methods inGitHubUserAccessStorewhere the failure isn't "you tried to write" but "this operation has no meaning in GitHub mode". Message text is accurate at each site — cosmetic, not a correctness bug.Fix: for 1, fix the javadoc or make
cloneAll()genuinely parallel (reuse theManagedExecutorGitHubStartupInitializeralready has). For 2, rename to something more general (GitHubOperationNotSupportedException) or add a second exception type for the non-write cases.(Surfaced during #3066's review.)