Reduce usage of legacy `CommandContext` in `IdDb`
🧢 Changes
Code cleanup with no user-visible changes.
☕️ Reasoning
When I started writing these commits, I thought that a good end goal would be to have IdDb and all its dependencies not use CommandContext at all. These commits definitely bring us closer there. However, right now, I'm wondering if the end goal should instead be to refactor "status" code by shifting the bulk of it into somewhere that can be referenced from Context, have that code both serve "status" and anything that requires ID interpreting or generating, and ensure that that code does not use CommandContext. These commits bring us closer there, but some of the code changed may end up being discarded.
I have been thinking about whether these commits should be merged - if it were up to me, I lean towards merging them, since they provide a better base for everyone to build on. But if code archeology (e.g. bisect, blame) is an important consideration, maybe it's better to wait until we have a better idea of what the end goal should be.
Related to #11263
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
| Project | Deployment | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| gitbutler-web | Preview | Nov 25, 2025 5:31pm |
Thanks for sharing detailed reasoning, I found it very helpful.
Having taken a quick look only, I think it's worthwhile to merge this PR. Indeed, I think Context shouldn't be used by anyone but some sort of 'top-level', which then passes down the pieces that are actually needed to where they are needed.
Using the new Context, however, will facilitate this.
Besides that, it's always good to refactor for familiarisation - it's basically what I do all the time 😅.
e07bb339c (Fold gitbutler-command-context into but-ctx., 2025-11-19) made this PR a lot smaller, eliminating the need for the first commit and drastically reducing the size of the second (the third remained unchanged). I've updated the PR accordingly and will merge it now.