I've finally been able to get most of the hard stuff isolated into this AheadBehindUpdater module, so I'll summarise the current flow of information around the Compare tab:

• selecting a repository sets up a AheadBehindUpdater to process and cache ahead/behind data
• inside AheadBehindUpdater it uses a queue (using the creatively-named queue package) to process actions in a first-in, first-out fashion
• the user performs some action that means we're probably interested in ahead/behind stats, triggering the AppStore to update it's state
• the AppStore passes the current AheadBehindUpdater a set of refs that need to be computed
• the AheadBehindUpdater ditches any in-flight work (basically because it's associated with an old HEAD) and queues up a number of tasks (using its cache to skip work it already knows is done)
• these tasks are processed serially by the queue, with each being prioritized with a requestIdleCallback to ensure it doesn't take away from anything else happening in the UI
• when a task is done, AheadBehindUpdater will signal back to the AppStore that it has some new values to use in the Compare tab

Things that are nice

• a unified ComparisonCache that tracks all ahead/behind stats for a repository avoids needing to depend on HEAD in a repository - there's now a risk that we might cache too much for large repos, but at least we now have one place to clean this up
• using the *Updater pattern like we've done with other components means we can push the complexity about scheduling work out of AppStore
• this strikes a nice balance between background work (using requestIdleCallback) and updating the UI (by emitting updates in AppStore) - this means if you're browsing a long list of refs the UI remains snappy, but will populate the ahead/behind stats as they become available. Here's a GIF:

Things that need work

• I'm still enabling other scenarios where HEAD changes under us and we need to update the compare view, being careful to ensure the background work doesn't interfere with the rest of the app. That's next.
• using ComparisonCache directly in AppState and then signalling every time it's updated feels excessive. It'd be great to just attach this to the branches we already track in our list, but I don't want to affect other parts of the codebase. Deferring thinking about this more until I've addressed other optimizations.

Would it be possible to run multiple ahead-behind checks at the same time so results show up faster?

Would it be possible to run multiple ahead-behind checks at the same time so results show up faster?

The current limit to concurrency is spawning Git processes - we have to spawn N Git operations to get the ahead/behind counts for N branches because rev-list only supports providing one range. Command line examples of this behaviour are just shell scripts wrapping this pattern.

Now, we could batch the onCacheUpdate calls so that they run N/3 times (so signal for each 3 calls) or something to avoid excessively re-rendering, but I think that's not hugely important here - and easy to adjust now we've got the core in place.