A Git client for simultaneous branches on top of your existing workflow

I think jj is super cool. But I like the idea of a killer GUI that makes so many things so fast and easy to do that I would use it instead of the cli. Ive never used a git gui for more than a day. Ive used GB daily for months and I love my dogfood.

But re:jj, Im pro anyone trying to do interesting things around VCS/Git. Its been a very long time of general complacency.

Cool, thanks! I am also in the "never used a git gui for more than a day" camp, so that makes a ton of sense! Looking forward to giving this a shot.

> 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!

This looks awesome. I've used git for over a decade and I always have to look up rebase, reset head, etc commands that I use maybe a few times a month.

> Undo, squash and amend your work by just dragging and dropping. No need to wrestle with rebase -i.

I think one thing that would be really cool to add to this and other git actions is to put the git commands that will be run based on the users inputs somewhere on the screen so the user doesn't COMPLETELY forget how to use git, and actually may get better at it with the additional help. Some may think that would lead people to not using gitbutler anymore, but no way, I am absolutely happy never having to write another git command beyond commit and push. Every time I have to do something I don't usually do in git it slows me down by 5+ minutes and it's super annoying and god forbid its a too-big PR that I have to cherry pick etc.

Also, another thing I am DYING for, none of my IDEs (intellij/vscode) as far as I know have extensions/options for it - if I do a commit and push in a vscode session, COLOR THE FILES SO I STILL KNOW WHAT I EDITED. DON'T UNMARK THEM AS EDITED. Make them yellow or blue or something, I don't care, just color them. You can absolutely track git diff / cache etc against 1 or 2 previous merges and base file colors on it. I do this all over my CI/CD scripts to determine whether or not we need to do a docker build/deploy etc or not based on files that diff from origin/main + your current branch 1 behind. If you didn't modify a Dockerfile, we don't do a docker buildx with your push.

I HATE when I have to commit/stash a massive PR with 30+ files edited because I need someone else to pull it or whatever and then have NO easy way to see what I changed in the commit vs main in my UI because as soon as I commit and push all of the tracked files change color to the "im just a file" grey color.

It causes me to commit a lot less when I should commit more. I'm pretty sure at some point I'll have to dive into js and write this myself. Probably just store modified files in a list and diff against main. I have an extension (wakatime) that tracks how long I've written code (not idle time at all, actual typing) in a BRANCH so you can definitely track a session based on something like your time writing code in a branch and cross reference that vs modified files.

The current branch I'm in I've written 4 hours of code in over 1-2 weeks, so I just need to know in that 4 hours what files I touched.

Typical use case for worktree(s) is to work on feature/hotfix branch without touching the current master/wip branch.

So, in the context of worktrees I read _"The way we're doing it, the branches are both in the same working directory at the same time"_ as having both the branch's files (not changes) available in the same worktree.

Thanks for clarifying that it is similar to changelists.