Working over SSH, à la VSCode Remote

[sigwinch28]

I often work on a remote development server, e.g. using VSCode's Remote SSH extension.

I would like to use GitButler in these environments as part of my regular development workflow, where the client/UI is running locally but the server is remote. Without this feature I can't realistically use GitBitler at work without some remote desktop solution like running a VNC server on the remote development server.

[schacon]

It's a good idea and we recently realized that there are people who have this type of work setup. We just started looking into what that might look like to implement, but I fear that it's non-trivial. On our list, but probably not coming up super soon.

[danlapid]

Any update on this feature, a possible timeline?

[lucaspar]

Seconding this - a TUI or CLI client would be a welcome and often required feature.

[codegod100]

My laptop is super small and under powered specifically because I have a remote workflow

[gaobrian]

Remote way is really helpful

[g-kartik]

I second this. Please avail a CLI tool as well which can easily be integrated into dev environments

[hulk510]

I’d love to see CLI support for committing to GitButler stacks when working over SSH (e.g. via VSCode Remote SSH).
Having this would really improve my ability to use GitButler across multiple machines in remote workflows.

Thanks for this discussion — it's been really helpful to read through.

I'm currently using GitButler on both my MacBook Air and Mac mini, and it's working well in those local environments. I really enjoy the UX and how it fits into my daily workflow.

Recently, I started working with AI-assisted tools and often switch between devices. Sometimes I need to make quick edits on a different machine via VSCode's Remote SSH extension. I found myself unsure how to commit properly in a GitButler-managed project from the remote side, which is how I came across this thread.

Of course, I can always push or create a PR and then continue working from the other device — that workflow works fine. But I was hoping for a lighter alternative, like being able to create commits directly from the remote server when needed.

So far, I've only used the GUI, so I'm not entirely sure what the CLI currently supports. If this is already possible and I've missed it, I apologize. But if there were a simple CLI option to do something like git commit (e.g., choosing a stack and committing to it), that would be really useful in remote or SSH-based workflows.

Also, I know it's technically challenging, but being able to use the GitButler GUI against remote targets would be amazing.

Lastly, since GitButler lets us work across multiple stacks, having a way to "focus" on a specific stack (similar to how git checkout works for a single branch) — even just one at a time — would be helpful in my use case. Personally, I don't need full multi-stack support on remote, as long as I can commit to a specific one when needed.

Thanks again for your great work!

[Byron]

Thanks so much for sharing your workflow!

So far, I've only used the GUI, so I'm not entirely sure what the CLI currently supports. If this is already possible and I've missed it, I apologize. But if there were a simple CLI option to do something like git commit (e.g., choosing a stack and committing to it), that would be really useful in remote or SSH-based workflows.

There is a new but CLI that does support creating commits from the command-line. Assuming the machines have a shared disk for the repository, with it you would be able to create commits on a machine that can't run the GUI. The command you'd be looking for is but rub, which right now can only amend to existing commits.

Also, I know it's technically challenging, but being able to use the GitButler GUI against remote targets would be amazing.

Absolutely - the application architecture would support it, but unfortunately tauri doesn't seem to support it out of the box just yet.

Lastly, since GitButler lets us work across multiple stacks, having a way to "focus" on a specific stack (similar to how git checkout works for a single branch) — even just one at a time — would be helpful in my use case. Personally, I don't need full multi-stack support on remote, as long as I can commit to a specific one when needed.

That's great to hear, as it's something we are working on. Then you could checkout any branch and GitButler would just be able to follow. There is still a couple of rough edges to be sorted, like how to recover when commits were create with Git despite the branch also being in a workspace - the latter would then have to be updated and restored. But it's something that will happen nonetheless, making working with GitButler the least-possible amount of intrusive.

Thanks again for your great work!

Thanks ☺️. And thank you for giving it a shot!

[hulk510]

Thanks so much for the detailed reply — really appreciate you taking the time to explain the current direction and rough edges.

I looked into but rub, and it seems like it’s not distributed as a standalone package or binary at the moment, but rather something you build manually via Rust (e.g., from crates/but/Cargo.toml). Please correct me if I misunderstood, but I assume that’s the intended way to use it for now?

Either way, it’s great to know that something like this exists already — I’m definitely going to try it out in my SSH workflow.

Also, I found it really helpful to read about the long-term vision for how GitButler will follow branches more seamlessly in the future. That sounds incredibly exciting, and I’m really looking forward to seeing how it evolves. The idea of making GitButler as non-intrusive as possible really resonates with how I like to work.

Thanks again — this discussion has been super insightful!

[Byron]

I looked into but rub, and it seems like it’s not distributed as a standalone package or binary at the moment, but rather something you build manually via Rust (e.g., from crates/but/Cargo.toml). Please correct me if I misunderstood, but I assume that’s the intended way to use it for now?

Sorry for the vagueness :). You should be able to get the but CLI into your path by clicking Actions, and install it by hitting the buttons there.

It's not particularly responsive when hitting the button, it seemed to do nothing even though it worked fine the first time I pressed it. There is also a manual way of doing it, and sudo doesn't seem to be required on MacOS, it wasn't for me at least.

Also, I found it really helpful to read about the long-term vision for how GitButler will follow branches more seamlessly in the future. That sounds incredibly exciting, and I’m really looking forward to seeing how it evolves. The idea of making GitButler as non-intrusive as possible really resonates with how I like to work.

🙌! A large amount of users is probably alienated by GB's invasiveness and many of those who aren't will be turned off by its correctness issues. We are working on correcting all of that and I can't wait to be able to use it myself then 😅.

[hulk510]

Oh, you’re right — I was able to install it successfully. Thanks so much! 🙌
Really appreciate all the work going into this amazing project. It’s been super helpful in my development workflow, and I’m genuinely excited to see where GitButler goes next.
Keep up the great work!