[schacon]

It works fine. The only thing that is a problem is “branch” and “commit”, things that use the index. But that makes sense. If you have setup two virtual branches and then from the cli run “git commit”, which branch do we commit to?

[trws]

This makes sense, but I have to say I would find it much less concerning if doing "commit" would apply to some well-defined selection. Either something marked in the UI as "default" or "first" or something so that normal git operations wouldn't cause failure. I realize it makes one of the virtuals special, which is unfortunate, but it means normal command line workflows would be _safe_ even if they wouldn't always provide all the options.

[schacon]

Two things. One is there is a commit dialog per virtual branch. You do a commit on a branch. The selection is all the files/hunks you see on that branch, or you can selectively commit parts of those changes (such as a add -i type commit). It's pretty much identical to how Git (or any other Git GUI) handles commit selection, except you can have more than one branch that you're working with, applied, at a time.

Also, GitButler, as far as I can think of, never causes normal git operations to fail. It doesn't put the project git repo in a state where git can't operate.

[trws]

That's great news, and I'll play with it some more to see if I misunderstood the docs. If so there may well be no issue here. Thank you for clarifying.

[OJFord]

If it were implemented as a 'rebased chain' as I described rather than a multi-head merge: the active one, just as vanilla `git commit` would.

[alexeiz]

> The only thing that is a problem is “branch” and “commit”, things that use the index.

A git branching tool that breaks git branch and commit - what a novel concept!