Hacker News new | ask | show | jobs
by XorNot 855 days ago
I'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.

1 comments

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.

For whatever reason this makes me think of having multiple worktrees in the same directory tree :) like .git (normal), git-1, git-2… so you have X HEADs. But that is probably way off anyway because of https://news.ycombinator.com/item?id=39374140