Replies: 1 comment
|
To be able to focus on other projects, I have to reduce the time I spend on Forge. That involves deciding to not implement certain features and I'm afraid this is one of those. Sorry. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Now I understand how the topics list works but I feel like it could interoperate a little nicer when operating on commands using completing-read.
To recap, at work there's a big Github repository that essentially everyone works on, and it tends to have about 1000 open PRs plus tens of thousands of PRs in its history. The operation I tend to use the most in
forgeis to check out a branch from a PR, which I used to initiate by doingb f, but I thinkb fis limited to the newest 200 / newest active 200 PRs. Instead I will be using the topic list to filter the set of PRs and then put point on the one I want, and then dob f RETthere.I wish there was a way to go from the minibuffer/completing-read of
b fto the topic list. My muscle memory is to start withb ffrom the Magit status buffer, and it feels a little unfortunate that I have to "back out" (C-gand thenN l tgo to the topic list) if the topic I want doesn't happen to be in the newest 200. Alternately, maybe it would be nice to have a way to use the topic filtering commands when in the minibuffer, but I infer that the direction the project is going is to make more use of topic lists, so maybe that's not as good an idea.I wish there was a way to use the currently-filtered list of topics as the set for a completing-read. So, I could use the topics buffer to filter down to the PRs from a specific person, and then use something like
b fto choose from only this set. As it is, it lets me select from the normal "newest 200 + whatever point is on", which seems less useful to me. This is true for all the commands in the "dispatch" menu too, which I found a little surprising.All reactions