What I'd like
A way to control how many requests stack makes to the code host at the same time, set through git config like the other options — for example:
git config stack.codeHostConcurrency 2
Why
Right now stack fires several code-host requests in parallel (it looks like 4 at a time). In my setup, that burst of simultaneous requests is too much and the calls start timing out, so stack fails partway through.
If I could set the number myself, I could find the sweet spot that works for me — maybe 3 or 2 is enough, and 1 as a worst case. Being able to tune it means stack finishes reliably instead of failing on the burst.
How I imagine it working
The number already exists in the code (codeHostConcurrency, default 4) but isn't exposed. It could be read from git config the same way stack.trunks and stack.blockLink already are:
git config stack.codeHostConcurrency 2 # two requests at a time
git config stack.codeHostConcurrency 1 # one at a time
git config stack.codeHostConcurrency 4 # current default
If it's not set, keep the current default of 4 so nothing changes for existing users.
What I'd like
A way to control how many requests stack makes to the code host at the same time, set through git config like the other options — for example:
Why
Right now stack fires several code-host requests in parallel (it looks like 4 at a time). In my setup, that burst of simultaneous requests is too much and the calls start timing out, so stack fails partway through.
If I could set the number myself, I could find the sweet spot that works for me — maybe 3 or 2 is enough, and 1 as a worst case. Being able to tune it means stack finishes reliably instead of failing on the burst.
How I imagine it working
The number already exists in the code (codeHostConcurrency, default 4) but isn't exposed. It could be read from git config the same way stack.trunks and stack.blockLink already are:
If it's not set, keep the current default of 4 so nothing changes for existing users.