Is there any way to increase the limit of 50 PRs per stack?
Setting aside opinions on whether stacks of that size are a good practice, I would be interested in understanding the technical or product rationale behind this hard limit. Is there a strong underlying reason for it, such as performance, scalability, or usability concerns?
From my perspective, reaching this limit is quite disruptive. Each time it happens, I have to spend a significant amount of time restructuring and fragmenting the stack, which adds overhead without providing any obvious benefit. While I understand that some users may consider very large stacks undesirable, that is ultimately a matter of workflow preference. What I am trying to understand is the actual reason for enforcing this restriction.
The more I work with large stacks, the more I find myself questioning whether this limitation is truly necessary.
Related to this, I believe the UI could do a much better job of communicating the total size of a stack. For example, if I have a main stack of 20 PRs and, at some point, a sub-branch of 10 additional PRs, the number shown depends on which PR is currently selected. If I select a PR on the main stack, the UI tells me the stack is 20 PRs long. If I select a PR on the 10-PR sub-branch, the UI shows only something like "10+", where the "+" represents the PRs below the sub-branch on which it is based.
This is very confusing because neither view clearly shows the total number of PRs involved in the overall stack structure. In practice, it forces users to manually count PRs to understand whether they are approaching or hitting the 50-PR limit. Given that the limit can have a significant impact on workflow, I would expect the UI to make this information much more explicit and readily available.
I would greatly appreciate any comments from the development team regarding both the rationale for the 50-PR limit and the possibility of improving the visibility of total stack size in the UI.