performance improvements and bug fixes

[Byron]

This PR is planned as follow-up to #4771, even though it chooses to pick other low-hanging fruit first.

This means, adding more instrumentation to find long-running functions or functions that run more than once in the same operation.
From there, one can avoid duplication, and optimize specific cases while keeping git2, at least at first.

Probably this will lead to this PR being merged early as it aims to deliver more small improvements while guiding the way towards
bigger improvements that would require gix, along with some upgrades to it which may take more time.

Tasks

• 2x performance (according to profiler) for list_remote_branches() (now list_local_branches())
• Fix Creating a virtual branch from a local tracking branch that isn't from GitButler duplicates commits #4795
  From
  
  To
  

Notes for the reviewer

• It's not actually a perfect fix, as I saw this while testing:
  
  And actually, it turned out that this is a similar looking, but different, commit, so it's correct after all.
• After unapplying, I saw that there are two duplicate commits which seem exactly the same (but have different patches). It was strange that the UI didn't show them combined anymore, maybe intentionally? Or maybe it's another implementation? It seems like it, so I didn't touch it.
  

Follow-Up

• accelerate is_commit_integrated() - octopus merge with trees as results
  

Notes

• When applying a branch in GitLab, it runs into the write-lock and operations block each other, with the last recalculation taking 20.4s (most of the time is waiting). Overall, this cascade of events seems very suboptimal.
  • I feel a lot of compute could be saved if the operation itself would emit whatever the UI needs, instead of relying on the watcher. The watcher could be deactivated/told to ignore what happens while the alteration is running. However, this also seems very complicated so it's probably better for now to make everything faster.
• It seems like list_local_branches() (formerly list_remote_branches()) is used to build a combined branches view, similar what the new list_branches does. It's hard for me to see how it's used, and it am surprised this information is still used anywhere as the side-bar definitely uses the new branch_listing now.
• It's clear that my tests of creating a vbranch from a local branch cause particularly bad performance when listing virtual branches due to their integration-commit checks.

Issues

These issues where created while processing this PR.

• Delete Branch can be triggered multiple times #4794
• Creating a virtual branch from a local tracking branch that isn't from GitButler duplicates commits #4795

References

• https://www.figma.com/design/FbeLt0yjY9RiNn8MXUXsYs/Client-design?node-id=2907-112917&node-type=CANVAS - branch states

[vercel]

@Byron is attempting to deploy a commit to the GitButler Team on Vercel.

A member of the Team first needs to authorize it.

[krlvi]

the list_remote_branches function is meant to be deprecated / removed entirely in favor of the new listing api that was already optimized. I think ideally we should figure out if there is anything this endpoint provides that is still needed and shift it somewhere else

[mtsgrd]

@Byron this seems to break amending of commits. If I have a virtual branch with an upstream and I amend the only commit it stays local and remote instead of becoming local (which can be force pushed).

[Byron]

Thanks for letting me know! I think this means that a patch-id also has to be computed to detect such changes. And that would make this operation quite expensive even though I think it can easily be accelerated by using all cores, i.e. compute patches in parallel.
I'd be glad to do that if you think that fixing the initial shortcoming, i.e. creating a virtual branch from a remote and having its commits displayed as "Local and remote" instead of separately, is worth it. If not, a revert would be in order.
Please let me know and I will submit a PR with the respective kind of fix.

[mtsgrd]

Hey thanks for responding so quickly. Iiuc we would want to display the list as if the branch was rebased, but it's difficult since the remote id's don't necessarily have change id's?

It feels like checking author, committer, and message is the right way to accomplish this, so I'm thinking the problem is in the front-end code. Instead of identifying the commit existing on both local and remote, it should be identified as local, but having been rebased. Let me see if I can fix this!

[mtsgrd]

See #4807!