Managing a subset of topics locally

[acolomb]

Hi! I'm just starting to get comfortable with forge, so probably finding some rough edges that might be a non-issue for daily users. I opted to check out only some topics, so all solutions involving "just fetch everything" are not suitable.

1. When visiting a topic, I expected there to be an easy way to fetch it for getting new posts. C-c C-c / f is available and of course N f t RET (since the latter asks for the topic number again). Shouldn't this be easier by default, e.g. C-c C-f to "fetch the thing"? The most convenient way should be mentioned in the docs section 6 "Visiting Topics" IMHO.

2. Next best choice would be a quick way to refresh all topics already in the current list (within magit status or the separate topics list buffer). I expected f n to do that, but apparently the new posts did not end up in the buffer visiting a specific PR. As if nothing was actually pulled - it's not quite clear what should be (all topics? refresh existing? current thing?) Even better if the active region would be respected, to fetch only marked topics (ref. Act on multiple issues at once #305).

3. It seems cumbersome to keep only certain topics locally. Is there a way to pull only open issues/PRs? #693 asked for limiting to open topics initially, but after some months you will (hopefully) end up with local entries for closed ones anyway. Cleaning that out should be easier than M-x forge-remove-topic-locally, as that operates only on a single entry. Marking several lines would be great here, and maybe a default binding for the k key, like other contexts in magit status. Combined with filtering, forgetting about closed stuff locally would be rather quick. And the hint for the + binding in Delete topic LOCALLY only (+ for all): doesn't seem to work for me. I can only enter a number, but when hitting + it simply does nothing. That would have been plan B, delete everything locally and fetch specific ones again.

4. Somehwat unrelated, I'm getting the hang of how forge and branch pulling interact. But I thought I had seen the related branch or head commit of a PR listed when expanding (TAB) the respective line in a PR list. But that no longer works, it just hides the small arrow indicating an expandable section, without adding further detail. Is that a bug?

Versions: Magit 4.2.0, Transient 0.8.2, Forge 0.4.6, Git 2.43.0, Emacs 29.3, gnu/linux

[tarsius]

I haven't forgotten about this, but it might take another week or two until I get around to taking a closer look.

[acolomb]

Ping? :-)

[tarsius]

1. I think both of these are fine as defaults (considering that most user would only use them in rare cases). You can of course add a more convenient binding for forge-pull-this-topic yourself.

2. This would involve two things. a) Getting the list of topics in the region, which is easy, that's already being done for other commands. b) Making a GraphQL request that asks for multiple topics. That's more involved and because major changes are required in this area anyway, I won't look into this particular request before I have tackled the refactoring. (The situation is worse when it comes to the Gitlab REST requests, so that will be the priority (and take a long time)).

3. Also a two part problem, but here the second step should be way simpler. I'll look into deleting multiple topics at once.

   + makes all (locally available) topics available as completion candidates. It doesn't act on all.

   One way to delete everything would be forge-remove-repository.

4. When only fetching individual topics, forge does not automatically add the refspec that causes all pull-request branches to be fetched. But you can M-x forge-add-pullreq-refspec.

[tarsius]

3b. forge-remove-topic-locally can now delete all topics marked using the region. I don't think this command should be bound by default.

[acolomb]

Sounds great, I'm looking forward to testing that!

[acolomb]

Great stuff, just tested with forge-20250220.1444. That's a nice solution for this aspect.

Would it be just as easy to offer the same treatment to fetching topics? As in N f t confirms the list of topics in region if it is active, instead of asking for a topic ID? And maybe even more commands, such as setting private status?

[tarsius]

Would it be just as easy to offer the same treatment to fetching topics?

Probably, but before upgrading more commands one by one, I would want to add some helper to make that easier. #305 is about this You could help there, by explicitly listing commands you think should be able to act on multiple topics.