In this video, GitButler CEO Scott Chacon introduces how to use virtual branches in the new GitButler alpha release. Work on multiple branches at once and more!
It is somehow counter-intuitive for me. Not sure if I'm doing it wrong. Say I get two virtual branches and each of them contains changes on the same file. I'm expecting we are able to switch between the "branches" and each branch does not interfere with others, but this is not the case. In reality, I can still see changes from both branches together, in my IDE.
The branch's you see in the lists are the active applied branches, you can unapply a branch for it to be "stashed" and it will be listed in the other branches ares. Switching between branches is applying the branches you want to see and unapplying the branches you don't.
@@tomm5765 So I hate this question, but how does that scale? if you have twenty branches, changing between them involves stashing nineteen and unstashing the one you're currently on?
@@RobertLipe No most of the time your branches are not applied. You would only have 20 branches "applied" if you were testing the 20 branches together.
Right now I'm a bit confused as to how this is different to git stashes but with names. Also, while the gui looks really nice, Isn't this something that could be implemented into git itself instead of a wrapper? If all of this needs to be essentially serialized into real branches, wouldn't this confuse the hell out of anyone using other git clients? Or if there's no chance git will introduce this, then shouldn't the implementation be a library or CLI that the GUI is built on top of, instead of the code just being somewhere in the GUI application?
Any time your business model "X, but with Y fixed" , you're at risk for X "fixing" it themselves? I mean, the original Norton Utilities QuickUnerase was a magic trick, but once DOS got Unerase, NU sales tanked. In one of the videos, they say that it's implemented in a way (as branches? I don't remember exactly) precisely so that other Git clients can see this and it's not just scribbling in the master repository. This is the team that made the original GitHub, so I'm willing to extend the assumption that they're not so bone-headed that they wouldn't trash the tree for other viewers - that would be pretty much a death sentence, I'd think. Is it probably implemented internally as a layer over the official Git library? That's probably how most people would tackle it, sure. Separating the GUI and the protocol implementation is just good sense. Disclaimer: I've downloaded it, but not even unpacked it yet. I've seen some videos, but have no inside scoop.
It's just like git, but you have to use a mouse, it's twice as slow, can't run in tmux, requires `ssh -X` (and much more bandwidth) if you want to run it remotely, can't run it in vim (`!git add .`)! But hey, anything to make my colleagues stop saying, "I couldn't figure it out, so I started over with a fresh clone" 😢
![Skilla Baby - Misfits (Feat. Polo G) [Official Video]](http://i.ytimg.com/vi/IjsylSnNMyw/mqdefault.jpg)
Great demo! Currently use Github Desktop but I'm excited to try out this virtual branches feature
Seems really handy, but I think it could easily lead to thinking a branch works when it doesn’t. I look forward to experimenting
It looks interesting
Awesome
What if I'm developing a virtual branch based on another virtual branch? Is that possible?
holy jee, came looking for gold and found diamonds
It is somehow counter-intuitive for me. Not sure if I'm doing it wrong.
Say I get two virtual branches and each of them contains changes on the same file. I'm expecting we are able to switch between the "branches" and each branch does not interfere with others, but this is not the case. In reality, I can still see changes from both branches together, in my IDE.
The branch's you see in the lists are the active applied branches, you can unapply a branch for it to be "stashed" and it will be listed in the other branches ares. Switching between branches is applying the branches you want to see and unapplying the branches you don't.
@@tomm5765 So I hate this question, but how does that scale? if you have twenty branches, changing between them involves stashing nineteen and unstashing the one you're currently on?
@@RobertLipe No most of the time your branches are not applied. You would only have 20 branches "applied" if you were testing the 20 branches together.
Make it as VS code extension
I believe we can see this in VS Code soon.
😭😭 deletes the commits if branch changed by terminal or another client
These are not actual git branches, this similar to jetbrains change lists
Was hoping it was going to be more like worktrees
I am gonna stick to plain git for now
Right now I'm a bit confused as to how this is different to git stashes but with names. Also, while the gui looks really nice, Isn't this something that could be implemented into git itself instead of a wrapper? If all of this needs to be essentially serialized into real branches, wouldn't this confuse the hell out of anyone using other git clients? Or if there's no chance git will introduce this, then shouldn't the implementation be a library or CLI that the GUI is built on top of, instead of the code just being somewhere in the GUI application?
Any time your business model "X, but with Y fixed" , you're at risk for X "fixing" it themselves? I mean, the original Norton Utilities QuickUnerase was a magic trick, but once DOS got Unerase, NU sales tanked.
In one of the videos, they say that it's implemented in a way (as branches? I don't remember exactly) precisely so that other Git clients can see this and it's not just scribbling in the master repository. This is the team that made the original GitHub, so I'm willing to extend the assumption that they're not so bone-headed that they wouldn't trash the tree for other viewers - that would be pretty much a death sentence, I'd think. Is it probably implemented internally as a layer over the official Git library? That's probably how most people would tackle it, sure. Separating the GUI and the protocol implementation is just good sense.
Disclaimer: I've downloaded it, but not even unpacked it yet. I've seen some videos, but have no inside scoop.
It's just like git, but you have to use a mouse, it's twice as slow, can't run in tmux, requires `ssh -X` (and much more bandwidth) if you want to run it remotely, can't run it in vim (`!git add .`)! But hey, anything to make my colleagues stop saying, "I couldn't figure it out, so I started over with a fresh clone" 😢