Edit: I now realize much (most?) of this already exist as part of the temporarily hidden Timeline feature in GitButler: https://docs.gitbutler.com/features/timeline Now we just need automatic (possibly virtual[1]]) commits that get created whenever one does a refactoring or other wide, sweeping tool assisted changes and soon my skills as dev archeologist would either become less valuable (because everyone can see wha…
A Git client for simultaneous branches on top of your existing workflow
31–40 of 119 posts
Re: A Git client for simultaneous branches on top of your existing workflow
#32I 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…
You should be able to do this pretty easily. We list your other local and remote branches in the sidebar. If you apply them, they are essentially converted into virtual branches (remote targets too, I believe)
Also, you I recommend that you add the capability to pull different hunks out of the commit, and separate/unsquash them, or even move them to different branches. The UI is begging me to drag parts of the commit out. I can squash commits, but it doesn't seem like I can do the opposite.
Use Case: Just now I made a change to a config file, and a build tool also updated the version in this same config file. I want to split the change out.
Using the CLI to split the commit, I would do this:
git add -p . # partial stage
s # for each hunk
For splitting the hunk into a branch, I would do this: git checkout -b new-branch-name
git reset HEAD^ # if I already staged it
git add -p
s # for each hunk
Using Magit, splitting out the commit: M-x magit-status
TAB # on the file diff
s # per hunk
e # when I need to refine it manually
Using Magit, to move hunks to a different branch: M-x magit-status
TAB # on the file diff
b c # new branch
b b # as needed, switch branches
Again, want to thank you for you work here. It's really nice, I already am getting my team onboarded to it.Re: A Git client for simultaneous branches on top of your existing workflow
#33There's a very similar feature which allows you to checkout multiple branches from a single repo, and comes out of the box with git. Try 'git worktree' https://git-scm.com/docs/git-worktree
Short answer is that worktrees dont exist in the same working directory like virtual branches do.
Re: A Git client for simultaneous branches on top of your existing workflow
#34Often I find myself maintaining a handful of "local" changes. I make some changes that only make sense in my local environment, that I don't want to push.
What I end up doing is maintaining these changes as a commit, committing on top of them, and using `git rebase -i` to periodically move them up. Then before I push, I have to temporarily rewind the branch to remove them, push, then cherry-pick them again.
It's all a bit awkward and I would love a tool that maintains a kind of "virtual branch" that isn't shown but is automatically re-based on top every time I make a commit, maybe letting me resolve conflicts or even telling me ahead of time if I've created one, before committing.
Someone must have already solved this, or am I doing it all wrong?
Re: A Git client for simultaneous branches on top of your existing workflow
#35Not sure this is something I need. One thing I do need though, maybe someone knows a solution: Often I find myself maintaining a handful of "local" changes. I make some changes that only make sense in my local environment, that I don't want to push. What I end up doing is maintaining these changes as a commit, committing on top of them, and using `git rebase -i` to periodically move them up. Then before I push, I hav…
Each developer can modify their .env however they want without having to make any changes visible to git.
Re: A Git client for simultaneous branches on top of your existing workflow
#36Not sure this is something I need. One thing I do need though, maybe someone knows a solution: Often I find myself maintaining a handful of "local" changes. I make some changes that only make sense in my local environment, that I don't want to push. What I end up doing is maintaining these changes as a commit, committing on top of them, and using `git rebase -i` to periodically move them up. Then before I push, I hav…
Re: A Git client for simultaneous branches on top of your existing workflow
#37'Virtual branches' is a nice idea, but I think the 'don't use other tooling' caveat probably makes it a no-go for me. It's not exactly the same, but since it's how I achieve the same goal currently, I wish it were implemented instead as automatic management of fork-points & rebasing the currently 'active' branch; even if there isn't one you consider 'active' so you want this merge, there still effectively is as soon…
Im not following you. What do you mean by “don’t use other tooling”?
Re: A Git client for simultaneous branches on top of your existing workflow
#38'Virtual branches' is a nice idea, but I think the 'don't use other tooling' caveat probably makes it a no-go for me. It's not exactly the same, but since it's how I achieve the same goal currently, I wish it were implemented instead as automatic management of fork-points & rebasing the currently 'active' branch; even if there isn't one you consider 'active' so you want this merge, there still effectively is as soon…
Im not following you. What do you mean by “don’t use other tooling”?
& see the description of 'the integration commit' for some detail of how they make it work:
https://docs.gitbutler.com/features/virtual-branches/integra...
Basically anything you do with `git` (or another GUI) will get blown away by GitButler; or if you change branch away from it then it will stop working.
Re: A Git client for simultaneous branches on top of your existing workflow
#39'Virtual branches' is a nice idea, but I think the 'don't use other tooling' caveat probably makes it a no-go for me. It's not exactly the same, but since it's how I achieve the same goal currently, I wish it were implemented instead as automatic management of fork-points & rebasing the currently 'active' branch; even if there isn't one you consider 'active' so you want this merge, there still effectively is as soon…
Im not following you. What do you mean by “don’t use other tooling”?
Re: A Git client for simultaneous branches on top of your existing workflow
#40'Virtual branches' is a nice idea, but I think the 'don't use other tooling' caveat probably makes it a no-go for me. It's not exactly the same, but since it's how I achieve the same goal currently, I wish it were implemented instead as automatic management of fork-points & rebasing the currently 'active' branch; even if there isn't one you consider 'active' so you want this merge, there still effectively is as soon…
Im not following you. What do you mean by “don’t use other tooling”?