3 ms·

I wonder how Magit was replaced. Magit is the sole reason I can use Git at all. I have never used Git from the command line, and every time I see non-Emacs-usin

I wonder how Magit was replaced. Magit is the sole reason I can use Git at all. I have never used Git from the command line, and every time I see non-Emacs-using coworkers trying to use git, it always seems like a mess the moment they do anything more complicated than switching branches. I remember briefly using the Git features in Xcode and IntelliJ, but both were pretty convoluted and lacked specific features I use daily, such as staging ranges of a diff (rather than an entire diff). There's also little things that make Magit essential to me, like cherry-picking a commit from the reflog having virtually identical UI to cherry-picking in general. Never bothered to try learning how to these things in Xcode or IntelliJ since the interface was complicated enough just to create commits and view a log. I don't use VS Code, but my coworkers that do use VS Code seem to use git entirely from a terminal window. So I am guessing VS Code doesn't have a Magit equivalent.

Derbasti 3y ago
Author here: I love magit. But at the end of the day, I mostly use it for simple stuff like committing, pushing, and the odd merge or blame. And these simple things also work very well with the IDE's git integration. For everything else, I stick to the command line. That's the only part of git that will always work no matter the interface. I find it easier to memorize, too, and it's of course much easier to search for online.
roryrjb 3y ago
There's edamagit[0] for vscode, it's pretty good! I've been using it for a couple of weeks now and haven't needed to touch git via the terminal. 0. https://marketplace.visualstudio.com/items?itemName=kahole.magit https://marketplace.visualstudio.com/items?itemName=kahole.m...
sporedro 3y ago
I come from a vim background and have used vscode and intellij as well. But picked up emacs solely due to magit. A coworker showed me it and I have to say it’s really amazing. Nothing really compares to it, the closest I’ve seen are the cli tools “tig” and “lazygit” but magit really outshines them feature wise. There’s nothing “similar” to it but vscode does have git tools, it just feels really clunky to use imo. Same goes for intellij’s UI. I guess it works for some people but they sort of just hurt my head to look at.
ak217 3y ago
VSCode has excellent git and github support (especially with the GitHub Pull Requests and GitLens extensions). In my workflow, it has surpassed anything Magit had to offer. While I still use the command line git extensively, I've come to rely on VSCode for a lot of the more complex contextual information available when editing, resolving merge conflicts, staging, and contextual git history available in popups. I always leaned on emacs due to its versatility working in remote environments on the command line. I still use it occasionally, but for me the feature that finally made me switch to VSCode as my main daily driver was the remote SSH plugin. It's a game changer and the best remote IDE experience I've ever had. Then Copilot came out and cemented the change. I think in general emacs and vi users learn to live with the UX and legibility issues of the software. I find vscode to be better at that. It strikes the right balance on a lot of things, in particular I find myself learning new things faster and with less frustration because the shortcuts, commands, and contextual information are more intuitive and in line with my expectations.
- koito17 3y ago
  > the feature that finally made me switch to VSCode as my main daily driver was the remote SSH plugin Have you tried using TRAMP? Depending on the specific backend chosen (ssh, scp, ...) it has varying levels of speed, but I have found it sufficient for my needs. Regarding Copilot, that's an interesting use case. It makes me wonder if other editors have extensions that try to recreate this experience. I wouldn't be surprised if Copilot is the killer feature of VS Code nowadays.
  - screcth 3y ago
    TRAMP is unusable if you have a high-latency connection. The UI thread blocks for a few seconds after every operation, which are really frequent if you use a complex configuration. The remote SSH plugin makes high-latency connections bearable, it's not perfect, but IO operations run in the background and so the UI thread does not block. I expect rewriting Emacs to use async IO to be a massive effort. It's difficult to write async code in Elisp.
  - ak217 3y ago
    TRAMP is unusable for my needs and doesn't really implement the remote IDE paradigm at all. I would argue that no IDE really implements the remote IDE paradigm aside from VSCode with the remote SSH plugin; it sets a new benchmark. I've tried several other IDEs and I haven't seen anything that works nearly as well. Take a look at the diagram here: https://code.visualstudio.com/docs/remote/ssh https://code.visualstudio.com/docs/remote/ssh - you will see that VSCode does not simply connect to the remote computer to read and write some files. It installs an entire VSCode server - seamlessly to the user every time they connect to a remote - that keeps track of all project facilities, shells, extension accessory runtimes, takes care of embedded or computationally heavy tasks like compiling, building, running project-wide code analysis tools, etc. while keeping all settings, editor windows, and accessory panes local (which is critical for UX and latency). VSCode appropriately partitions responsibilities between the local and the remote, automatically restores IDE infrastructure on the remote as needed, and enforces the partitioning architecturally for all extensions. These latency optimizations and offloads are not ad hoc; they are rooted in VSCode's origin as a browser-based IDE, and make use of the LSP and other architectural features that simply don't exist in Emacs because nobody really thought deliberately about running the extensions at an arm's length from the editor UI in Emacs, using an async protocol that doesn't allow extensions to impact core UI latency. A routine issue with TRAMP is that some unrelated plugin makes editing very slow and subject to random freezes because it expects low-latency I/O to the file being edited and to other accessory files next to it. This is a major issue that absolutely kills editing UX and confidence. It doesn't really happen with VSCode (worst case, the red squiggles show up a few seconds late), and just as importantly, the entire project behaves predictably because it's not just TRAMP running on the remote but the entire IDE infrastructure. Ironically, I think Emacs' origin on X-based systems foreclosed on the architectural possibility of a clean separation of concerns that can be seen in browser-based IDEs; it would be wildly disruptive to the package ecosystem.

Derbasti 3y ago

Author here: I love magit. But at the end of the day, I mostly use it for simple stuff like committing, pushing, and the odd merge or blame. And these simple things also work very well with the IDE's git integration. For everything else, I stick to the command line. That's the only part of git that will always work no matter the interface. I find it easier to memorize, too, and it's of course much easier to search for online.

roryrjb 3y ago

There's edamagit[0] for vscode, it's pretty good! I've been using it for a couple of weeks now and haven't needed to touch git via the terminal. 0. https://marketplace.visualstudio.com/items?itemName=kahole.magit https://marketplace.visualstudio.com/items?itemName=kahole.m...

sporedro 3y ago

I come from a vim background and have used vscode and intellij as well. But picked up emacs solely due to magit. A coworker showed me it and I have to say it’s really amazing. Nothing really compares to it, the closest I’ve seen are the cli tools “tig” and “lazygit” but magit really outshines them feature wise. There’s nothing “similar” to it but vscode does have git tools, it just feels really clunky to use imo. Same goes for intellij’s UI. I guess it works for some people but they sort of just hurt my head to look at.

ak217 3y ago

VSCode has excellent git and github support (especially with the GitHub Pull Requests and GitLens extensions). In my workflow, it has surpassed anything Magit had to offer. While I still use the command line git extensively, I've come to rely on VSCode for a lot of the more complex contextual information available when editing, resolving merge conflicts, staging, and contextual git history available in popups. I always leaned on emacs due to its versatility working in remote environments on the command line. I still use it occasionally, but for me the feature that finally made me switch to VSCode as my main daily driver was the remote SSH plugin. It's a game changer and the best remote IDE experience I've ever had. Then Copilot came out and cemented the change. I think in general emacs and vi users learn to live with the UX and legibility issues of the software. I find vscode to be better at that. It strikes the right balance on a lot of things, in particular I find myself learning new things faster and with less frustration because the shortcuts, commands, and contextual information are more intuitive and in line with my expectations.

koito17 3y ago
> the feature that finally made me switch to VSCode as my main daily driver was the remote SSH plugin Have you tried using TRAMP? Depending on the specific backend chosen (ssh, scp, ...) it has varying levels of speed, but I have found it sufficient for my needs. Regarding Copilot, that's an interesting use case. It makes me wonder if other editors have extensions that try to recreate this experience. I wouldn't be surprised if Copilot is the killer feature of VS Code nowadays.
- screcth 3y ago
  TRAMP is unusable if you have a high-latency connection. The UI thread blocks for a few seconds after every operation, which are really frequent if you use a complex configuration. The remote SSH plugin makes high-latency connections bearable, it's not perfect, but IO operations run in the background and so the UI thread does not block. I expect rewriting Emacs to use async IO to be a massive effort. It's difficult to write async code in Elisp.
- ak217 3y ago
  TRAMP is unusable for my needs and doesn't really implement the remote IDE paradigm at all. I would argue that no IDE really implements the remote IDE paradigm aside from VSCode with the remote SSH plugin; it sets a new benchmark. I've tried several other IDEs and I haven't seen anything that works nearly as well. Take a look at the diagram here: https://code.visualstudio.com/docs/remote/ssh https://code.visualstudio.com/docs/remote/ssh - you will see that VSCode does not simply connect to the remote computer to read and write some files. It installs an entire VSCode server - seamlessly to the user every time they connect to a remote - that keeps track of all project facilities, shells, extension accessory runtimes, takes care of embedded or computationally heavy tasks like compiling, building, running project-wide code analysis tools, etc. while keeping all settings, editor windows, and accessory panes local (which is critical for UX and latency). VSCode appropriately partitions responsibilities between the local and the remote, automatically restores IDE infrastructure on the remote as needed, and enforces the partitioning architecturally for all extensions. These latency optimizations and offloads are not ad hoc; they are rooted in VSCode's origin as a browser-based IDE, and make use of the LSP and other architectural features that simply don't exist in Emacs because nobody really thought deliberately about running the extensions at an arm's length from the editor UI in Emacs, using an async protocol that doesn't allow extensions to impact core UI latency. A routine issue with TRAMP is that some unrelated plugin makes editing very slow and subject to random freezes because it expects low-latency I/O to the file being edited and to other accessory files next to it. This is a major issue that absolutely kills editing UX and confidence. It doesn't really happen with VSCode (worst case, the red squiggles show up a few seconds late), and just as importantly, the entire project behaves predictably because it's not just TRAMP running on the remote but the entire IDE infrastructure. Ironically, I think Emacs' origin on X-based systems foreclosed on the architectural possibility of a clean separation of concerns that can be seen in browser-based IDEs; it would be wildly disruptive to the package ecosystem.