Improved integration

[Caleb-T-Owens]

---

This is part 2 of 2 in a stack made with GitButler:

•  2  Improved integration #5893 👈
•  1  Introduce commit subset check (part of stack) #5881

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
gitbutler-components	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 9, 2025 11:24am
gitbutler-web	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 9, 2025 11:24am

[Caleb-T-Owens]

Old time:
13.4s
New time:
107ms

I don't know how.

[Caleb-T-Owens]

This makes working on gitlab downright usable

[Byron]

Old time: 13.4s New time: 107ms

I don't know how.

That's crazy awesome 🙌! It's probably doing much less work than before to do it, which is great if one can get away with it. Maybe previously, it did way too much work as well.

107ms on a repo of GitLab size is probably no more than a merge or two.

[Caleb-T-Owens]

fuck... it was too good to be true.

this is indeed slower, and is slower by a fair bit.

[Caleb-T-Owens]

@Byron / @krlvi Shall we still merge this despite the performance issues as it's behind a feature flag anyway.

[Byron]

I think there is serious value in being able to detect if commits are integrated despite squashes. Of course, I am still concerned about the high runtime, which was high before and now is even higher.

[Caleb-T-Owens]

Of course, I am still concerned about the high runtime, which was high before and now is even higher.

Indeed. I wouldn't consider removing the feature flag that it is currently under without some serious performance improvements.

Perhaps however it's just unwanted overhead with the fork in the logic. I just don't really want it to go stale

[Caleb-T-Owens]

@krlvi wdyt?