After watching your (very enjoyable) talk in the other thread, schacon, one thing struck me - there _is_ a way to work on multiple branches at the same time: worktrees.
What's the advantage of a tool like this over that?
A Git client for simultaneous branches on top of your existing workflow
11–20 of 119 posts
Re: A Git client for simultaneous branches on top of your existing workflow
#12I'm very unclear why this "takes over" the git repository to work. Like even if that was absolutely necessary - and who am I to say it's not - ...surely the "actual" repository can simply live somewhere else and be manipulated?
How do virtual branches differ so completely that managing them isn't just a bunch of behind the scenes checkout/commit commands being issued to another repository somewhere, even if the local worktree needs to be separate?
Particularly because the idea of their being a base branch for virtual branches is pretty much the git branching model. Git and it's tools understand this perfectly fine provided you're using branches, and moving things between branches is supported via cherry-pick.
Re: A Git client for simultaneous branches on top of your existing workflow
#13After watching your (very enjoyable) talk in the other thread, schacon, one thing struck me - there _is_ a way to work on multiple branches at the same time: worktrees. What's the advantage of a tool like this over that?
Ha! That’s exactly what I do personally, and I had the same reaction. Worktrees are awesome.
Re: A Git client for simultaneous branches on top of your existing workflow
#14After watching your (very enjoyable) talk in the other thread, schacon, one thing struck me - there _is_ a way to work on multiple branches at the same time: worktrees. What's the advantage of a tool like this over that?
It's a good question, I was just working on a blog post - both because worktrees are very cool and also because I think we have a nice alternative to a similar issue.
With worktrees you can have different branches in different working directories and work on them at the same time. But practically, there is very little difference to just cloning the repo twice and working on different branches in the two checkouts.
The way we're doing it, the branches are both in the same working directory at the same time.
This can have a couple of advantages - one is if you have an annoying bugfix and you need it in order to keep working on your feature, you can have them both applied but you don't have to commit one into the history of the other. You cannot do this with worktrees.
Another is trying out multiple branches together. If they don't conflict, you can essentially get the result of a multi-way merge without creating any merge artifacts. Say you merge three work in progress branches to test them together, then keep working on each independently. Also, in this case, you _know_ that you can merge them in any order and the result will work because you've actually worked on the merged tree.
Re: A Git client for simultaneous branches on top of your existing workflow
#15I'm very unclear why this "takes over" the git repository to work. Like even if that was absolutely necessary - and who am I to say it's not - ...surely the "actual" repository can simply live somewhere else and be manipulated? How do virtual branches differ so completely that managing them isn't just a bunch of behind the scenes checkout/commit commands being issued to another repository somewhere, even if the local…
There's a lot here that is a little confusing, because I don't think almost any of what you're saying is what we're doing.
It does not take over your repository. We try pretty hard to not touch as much as possible. We do have a second place where we store metadata on everything we're doing, but it's not in your git repo. If you delete us, your repo is only very minimally added to.
We can't do virtual branches by wrapping git concepts and data structures, because there is just no concept of more than one applied branch. HEAD can only point to one thing, we're trying to make the concept of HEAD be able to be more than one thing and land changes on any of them depending on where you want each hunk to go. Git just cannot do this. It has one HEAD and one index and we need multiple of each for what we're trying to accomplish. We try to be tool-compatible and touch as little as possible. We update the index to match what is likely expected - ie, make a normal `git status` match the list of files you see in your GitButler workspace as changed, etc. We write out `refs/gitbutler/[branch]` for each virtual branch you manage, so you have real git refs to work with. But there are lots of things we want to do that Git simply does not have data structures for.
Finally, Git does not have a concept of a base or default branch. There is no special branch in Git. You have HEAD, but that changes. You have tracking branches, but that's per branch. Nothing in Git proper says 'origin/master' is special in some way except convention. The tool itself has no idea what is the "main" branch. GitHub does, with it's "default" branch, but Git does not.
Re: A Git client for simultaneous branches on top of your existing workflow
#16This seems like an incredibly poor idea to me. You now have the problems of rebase (your commits no longer represent a consistent repo snapshot), but even worse (your commits _never_ represented a consistent repo snapshot!).
Is there a way to identify commits made by GitButler? Can I configure my host to reject them automatically?
And the "generate a commit message for me" button really nails the kind of poor decisions that lead here.
Re: A Git client for simultaneous branches on top of your existing workflow
#17This seems like an incredibly poor idea to me. You now have the problems of rebase (your commits no longer represent a consistent repo snapshot), but even worse (your commits _never_ represented a consistent repo snapshot!). Is there a way to identify commits made by GitButler? Can I configure my host to reject them automatically? And the "generate a commit message for me" button really nails the kind of poor decisio…
I think there may be a misunderstanding here. While the tool does something unorthodox locally, the output that it generates is plan Git trees that do represent a consistent snapshot.
It is the process of arriving at those snapshots (locally) that we feel we can make more ergonomic.
Disclaimer: I am a Co-founder
Re: A Git client for simultaneous branches on top of your existing workflow
#18This seems like an incredibly poor idea to me. You now have the problems of rebase (your commits no longer represent a consistent repo snapshot), but even worse (your commits _never_ represented a consistent repo snapshot!). Is there a way to identify commits made by GitButler? Can I configure my host to reject them automatically? And the "generate a commit message for me" button really nails the kind of poor decisio…
GitButler creates normal Git commits and trees with libgit2. It's not dissimilar to using a tool that implements it's own interactive adding or something. The point is that Git is the database and Git hosts (such as GitHub) matter in our workflows, but actually creating the trees that represent the trees you want to share can happen in any way. We are changing how to conceptualize and execute how to get the trees you want, but the output is Git objects.
Re: A Git client for simultaneous branches on top of your existing workflow
#19I started using this yesterday. I'm a little unsure how to pull multiple real branches into my workspace. It'd be nice if I could have a virtual branch overlay a real branch so that I could continue working with both the advantage of GitButler and maintain productivity with colleagues that don't use it. As it stands right now, I'm a bit unclear on how to operate with others who use the old fashioned branching strateg…
The CRDT thing happens in GitButler, but we hid the UI to search and find old changes for now (you can see what it looked like here: https://docs.gitbutler.com/features/timeline). We still record the data locally and could theoretically recreate the state of your working directory and branches at any time. If you're curious, join our Discord and I can show you how we're storing it, you could easily use it in interesting ways until we resurrect a UI for it.
Re: A Git client for simultaneous branches on top of your existing workflow
#20After watching your (very enjoyable) talk in the other thread, schacon, one thing struck me - there _is_ a way to work on multiple branches at the same time: worktrees. What's the advantage of a tool like this over that?
It's a good question, I was just working on a blog post - both because worktrees are very cool and also because I think we have a nice alternative to a similar issue. With worktrees you can have different branches in different working directories and work on them at the same time. But practically, there is very little difference to just cloning the repo twice and working on different branches in the two checkouts. Th…
Reminded me of a product called Rational ClearCase:
> It uses the MultiVersion File System (MVFS) which is a virtual file system that displays specific versions of data stored. In particular, it supports dynamic views which can show an arbitrary combination of local and remote files