[OJFord]

Sorry I didn't realise you worked on GitButler when you asked.

> But if you have multiple branches applied, some git commands wont make any sense.

Sure, because of the way it's implemented. But that's just a variation on what I said really - I like the idea, see value in automating some management so that I can see & work on something that's the amalgamation of multiple branches, but I don't want to (have to) go 'all in' on some third-party tool, it needs to work like an extension of vanilla git for me, so everything else can keep working as normal.

It needs to be implemented in 2D so that git CLI can still understand, to put it in the docs' terms.

[schacon]

Just to clarify, yes, in order to work on multiple simultaneous branches, you need a tool that knows what that means, which git does not really. But you can also very easily run 'git checkout main' and do whatever and then go back to GitButler and restore state. It's pretty good at knowing what mode you're in.

Basically all your virtual branches also live in refs/gitbutler/[name] and GB won't touch stuff in refs/heads/ because we like the idea of making sure we're not clobbering things you don't expect us to. You can just think of GitButler as a tool for managing refs/gitbutler branches.

All git tooling work totally fine, even generally if you're using something (like commit) that doesn't really make sense in the context of multiple branches.