Hey! Thanks for the shout-out! Just wanted to clarify that GB's virtual branches dont use multiple worktrees but instead utilizes a managed reference where the branches are continuously integrated with an octopus merge on top to simulate one integrated branch :)

Working very hard right now to squash all of them bugs! Sorry for the inconvenience

It maintains real git references with an integration octopus merge on top that is checked out. This way you get an “integrated” work tree while being organise changes in separate branches

Oh nice! We should perhaps meet some time - beers on GitButler :)

Thanks for sharing this! Gonna take a look today. There is definitely room for improving the layout so this is helpful.

To add a little big more context - We are also working to re-enable allocating uncommitted changes to lanes, which prompts some further layout adjustments too.

Hey, sorry for the late reply here - been working really hard the past few days incorporating feedback. Here's how the app looks like on the latest nightly build.
More improvements are on the way too

Thank you for taking the time to share your feedback, Barry! 🙇‍♂️
I agree with you - something was lost in this transition. We are currently exploring options to bring back the lane view.

Stay tuned - the plan is to make a new release later this week so that we can gather another round of feedback.

It's not your fault - the app should do better. Currently, if the changes 'touch', GB treats it as if they intersected... which can lead to this kind of confusion.

Soon the app will allow partial committing (vid below) & it will be possible to handle this better. Thanks for being patient with us! 🙇‍♂️

The reason for this is that the 'lanes' are meant to be 'peers' - independently apply-able branches. In the case where dependency is desired, GB has support for stacked branches:
docs.gitbutler.com/features/sta...

I am sorry for the confusion! In general, changes are "locked" because they depend on a preceding commit.

For example if you create a function and then commit it, and subsequently make a change to that function, that change is "locked" to the lane.

It only makes sense in the context of the commit

This is incredible! Just seeing it for the first time myself :)

🤌

Feel free to hit us up if you have any feature requests or run into a bug :)

"Are you a complicated Pull Request? Because you look good to me!"

I hear this is a good pick up line

This one is one of my all time favs. Should do a rewatch of it

Let's do it, I plan to be there

What are your thoughts on commit based review? (As opposed to branch based like PRs)