mirror of
https://github.com/firstsun-dev/git-files-sync.git
synced 2026-07-22 17:20:30 +00:00
c7ae0f6754
User reported push-all was still slow on GitHub after the one- commit-per-run batching landed. Root cause: GitHubService/ GiteaService.pushBatch still created each file's blob with a sequential for loop -- one POST .../git/blobs awaited fully before the next started -- so wall-clock time was still O(N) round trips of pure latency even though only one commit came out the other end. - Add BaseGitService.mapWithConcurrency<T,R>: an order-preserving, bounded-concurrency mapper (worker-pool over a shared cursor). - Add BLOB_CREATE_CONCURRENCY = 8 alongside MAX_BATCH_PUSH_SIZE. - GitHubService/GiteaService.pushBatch now create blobs via mapWithConcurrency instead of a for loop; the tree/commit/ref sequence after it is unchanged since each step genuinely depends on the previous one's result. - GitLab is unaffected -- its pushBatch already sends the whole batch in one Commits API request, no per-file blob step to parallelize. Added a regression-guard test: deferred blob-response promises that only resolve after every blob POST has been dispatched, so a reintroduced sequential loop deadlocks the test instead of silently passing. Evidence: npx eslint . -> 0 errors; npm run build -> clean; npx vitest run -> 340/340 passed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| i18n | ||
| logic | ||
| services | ||
| ui | ||
| utils | ||
| changelog.test.ts | ||
| setup.ts | ||