Walking through Vcs Log table with keyboard triggers mining for each commit.

[jetbrains-research]

Walking through Vcs Log table with keyboard triggers mining for each commit.

[juliabeliaeva]

@ioanasv I think if user selects a commit, they want to see refactorings quickly, and don't want to wait for the queue to process other previously selected commits. Maybe on selection processing of the previous commits could be cancelled, and processing of the new one should start immediately? IntelliJ IDEA does a similar thing for changes in the changes browser, and it works pretty well. However, it requires processing of the selected commit to be cancellable.
If the process of mining refactorings is not cancellable, then maybe a stack with a limited size would fit. This way the newest commits would be processed right away, and the oldest commits would be dismissed if the stack would be too big.

[ioanasv]

Hello Julia, thank you! This is indeed an issue when there are many commits that are mined at the same time. We were thinking to keep mining them but in a smarter way so that it does not freeze the ui: using a pool and when there are already commits that are mined there, add the job to the pool and wait for others to finish in order to mine the new one. This is done somehow using a queue for the commits that are waiting to be mined. What do you think about it? At the same time, if the user clicks on many commits, usually she/he will not go back to those first commits in the list, so this queueing might not be helpful all the time.