Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

gitbutler.com

Post reply on HN
Print view View original

61–70 of 119 posts

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

#61

Post by schacon »

OJFord wrote: post #57
videlov wrote: post #53

Earlier quoted context omitted.

This limitation stems from the fact that GB introduces an additional dimension of versioning on top of Git. One way of thinking of what it does with virtual branches is like "multiplexing" multiple branches onto the same working directory. On the way out they get "demuxed" into plain git trees. With that said, the tool is very cautious not to mess with any existing branches. This is the very reason it operates on a s…

Maybe the problem is that the docs aren't selling me anything that I don't currently achieve by (manually) rebasing? So I'm left thinking I'd rather stick with my current workflow (or maybe motivated to alias it up a bit more) than adopt this limitation.

Well, one thing we can do is "merge" together multiple non-conflicting branches in your working directory without creating (or, I suppose, having to undo) merge artifacts.

Like if you had three branches and you wanted to see how they will work when they're all merged, and you find an issue in one and want to fix it, GB makes this really simple. You just apply them all and then fix something and make sure it's on the right branch and commit there (and push again if you want).

With Git, you would have to actually do either two merges or a three-head merge, see how it goes, undo the merge, switch to the target branch, commit a fix there, re-merge them all to see if that worked, etc. In Git there isn't a _real_ great way to combine trees without modifying history. We make those things a little more orthogonal.

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

#62

Post by gregmac »

thfuran wrote: post #36
radarsat1 wrote: post #34

Not 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…

It sounds like a project structure issue where local environment config that shouldn't be tracked is (or a lack of optional additional config that could be specified locally). Or maybe I'm misunderstanding the sort of change you're talking about.

This is what I thought, too.

I generally try to have support for this in the application, using a `.local` config file override which is in .gitignore. If one person has this trouble, chances are the rest of the team does too, and making this change is usually less time than the team collectively spends messing with it in a week.

Sometimes there's an existing workflow everyone just accepts (project in a specific path; some dependency manually installed locally; specific HOSTS alias to the database server IP; etc) but so long as you don't break that while also making it better/easier, I've found it's usually accepted.

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

#63

Post by reyqn »

adrianmonk wrote: post #28
ckolkey wrote: post #11

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?

Don't worktrees require more work to actually run your code because of multiple working directories? If you're using an IDE, you'll probably need to create a project for each working directory. Or maybe you can change the path within the IDE's project. If you're running a local web server, it will need to be configured for each working directory, again either multiple instances or one where you keep updating the path…

Maybe I don't understand how gitbutler works, but the main reason I use worktrees is actually to keep my IDE and incremental builds getting confused when I switch branches, on branches that have lots of differences. It works really well, and I can fix stuff on old versions of our app in a jiffy.

I wouldn't use gitbutler for what I use worktrees, and I wouldn't use worktrees for what I think gitbutler is aiming at.

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

#64

Post by schacon »

trws wrote: post #56
schacon wrote: post #45

Earlier quoted context omitted.

It works fine. The only thing that is a problem is “branch” and “commit”, things that use the index. But that makes sense. If you have setup two virtual branches and then from the cli run “git commit”, which branch do we commit to?

This makes sense, but I have to say I would find it much less concerning if doing "commit" would apply to some well-defined selection. Either something marked in the UI as "default" or "first" or something so that normal git operations wouldn't cause failure. I realize it makes one of the virtuals special, which is unfortunate, but it means normal command line workflows would be _safe_ even if they wouldn't always pr…

Two things. One is there is a commit dialog per virtual branch. You do a commit on a branch. The selection is all the files/hunks you see on that branch, or you can selectively commit parts of those changes (such as a add -i type commit). It's pretty much identical to how Git (or any other Git GUI) handles commit selection, except you can have more than one branch that you're working with, applied, at a time.

Also, GitButler, as far as I can think of, never causes normal git operations to fail. It doesn't put the project git repo in a state where git can't operate.

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

#65

Post by schacon »

bdcravens wrote: post #37
schacon wrote: post #30

Earlier quoted context omitted.

Im not following you. What do you mean by “don’t use other tooling”?

I think many developers don't want to have to jump to another tool. Myself, I've found the VS Code git client "good enough" (even though I have a Git Tower license). Are there plans for extensions for the tools that support them?

Maybe, but I think most developers are fine jumping to another tool if it makes what they do every day easier or faster.

Our goal isn't to replicate all the commands git can do. It's to try to create an interface for writing Git commits/trees that fits a more typical workflow. The UI is pretty different, but the end result is the same. If we can do that _faster_ than you can do on the command line or with another GUI, most developers are pretty pragmatic and will consider it. That is to say, if we do it well.

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

#66

Post by schacon »

OJFord wrote: post #60
radarsat1 wrote: post #34

Not 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…

I think this tool would help that, because you'd stick your only-makes-sense-for-you changes on `my-eyes-only` branch; that branch would always be in your 'integration' commit, along with whatever other 1+ branch(es) you were working, and you'd just only push the latter. That said even without GitButler you can improve it a bit: you can `git push HEAD^: ` rather than 'temporarily rewinding the branch to remove them'.…

This is true. For the use case you're talking about, just sticking some changes in a semi-ignored virtual branch basically will do what you are talking about. :)

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

#67

Post by videlov »

OJFord wrote: post #57
videlov wrote: post #53

Earlier quoted context omitted.

This limitation stems from the fact that GB introduces an additional dimension of versioning on top of Git. One way of thinking of what it does with virtual branches is like "multiplexing" multiple branches onto the same working directory. On the way out they get "demuxed" into plain git trees. With that said, the tool is very cautious not to mess with any existing branches. This is the very reason it operates on a s…

Maybe the problem is that the docs aren't selling me anything that I don't currently achieve by (manually) rebasing? So I'm left thinking I'd rather stick with my current workflow (or maybe motivated to alias it up a bit more) than adopt this limitation.

I think you are right that our documentation does not sufficiently communicate what the application does especially in various corner cases.

For my own sake, allow me to articulate the core value proposition once more. GitButler's virtual branches permit two novel use cases:

- A developer can lazily assign diffs/changes to belong to separate logical branches while maintaining their content within the same working dir. Those logical branches can be converted to plain git trees at any time. The canonical use case here is doing a bugfix while working on an unrelated feature - with the proposed workflow one can separate those contributions into discrete PRs while still having the content of both within the working dir.

- A developer can apply and unapply the content of remote branches to their working directory for the purpose of testing & review. This is distinct from rebasing and merging because it does not introduce merging or rebasing into the branch that the developer was originally working on.

In any case, we will work on communicating and documenting the tool better.

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

#68

Post by schacon »

devsda wrote: post #41
Tempest1981 wrote: post #20

Earlier quoted context omitted.

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 https://en.m.wikipedia.org/wiki/Rational_ClearCase

Yeah, this sounds very much like a 'view' in clearcase. It's a good feature especially with big monorepos where it is helpful to pick and choose a known good version of specific module or subset of files without polluting the history. Tracking good versions of every single file with huge number of files changing was a pain though.

I haven't used ClearCase, but from the description, I don't think it's much like a view. It's closer to IntelliJ's changelists, but without many of the limitations.

It's effectively a way to take changes you're making and pretend like you did them in worktrees without having to switch back and forth.

Or maybe, to work on several branches, achieve the merged state you want, then split the work up into reviewable branches that can be merged in any order to achieve that final state.

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

#69

Post by schacon »

reyqn wrote: post #63
adrianmonk wrote: post #28

Earlier quoted context omitted.

Don't worktrees require more work to actually run your code because of multiple working directories? If you're using an IDE, you'll probably need to create a project for each working directory. Or maybe you can change the path within the IDE's project. If you're running a local web server, it will need to be configured for each working directory, again either multiple instances or one where you keep updating the path…

Maybe I don't understand how gitbutler works, but the main reason I use worktrees is actually to keep my IDE and incremental builds getting confused when I switch branches, on branches that have lots of differences. It works really well, and I can fix stuff on old versions of our app in a jiffy. I wouldn't use gitbutler for what I use worktrees, and I wouldn't use worktrees for what I think gitbutler is aiming at.

Since we write out our virtual branch artifacts into refs/gitbutler/X, you could actually pretty easily setup worktrees from each of them to do this type of work on. Perhaps setup a post-commit hook to update any active worktrees automatically too. Might be an interesting way to effectively work on several worktrees from a single working directory.

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

#70

Post by schacon »

motoboi wrote: post #29

Intellij IDE support this through changelists. UPDATE: add link to documentation https://www.jetbrains.com/help/idea/work-on-several-features...

Sort of, but it's honestly closer to normal git branches. If I'm not mistaken, you can't have multiple changelists applied simultaneously. You still have to switch between active groups of changes, no?
Post reply on HN