
Show HN: Magit for VSCode (Alpha) - kahole
https://marketplace.visualstudio.com/items?itemName=kahole.magit
======
pcr910303
Wow, that definitely looks like a good magit replica in VSCode.

As someone who suggests every git user to try out magit (without all of the
Emacs stuff that others dislike) because it provides a great mental model on
how git works, this is very useful to people who use VSCode.

Some suggestions:

* Looks like the command UI is enabled through the VSCode command bar(? I'm not sure of the name) much alike Helm, but I think that the popup window style used in magit allows much more discoverability - a UI similar to that would be preferable.

* Just using the name magit inside the plugin name might not be the best naming; A rebranding would be better I think.

------
tarsius
Here are some articles that explain how (the original) Magit is different from
other Git clients:

* [https://emacsair.me/2017/09/01/the-magical-git-interface](https://emacsair.me/2017/09/01/the-magical-git-interface)

* [https://emacsair.me/2017/09/01/magit-walk-through](https://emacsair.me/2017/09/01/magit-walk-through)

------
mdszy
What benefits does this bring over the built in vscode git commands?

~~~
febeling
Magit, together with maybe Org-mode, is one of the Emacs packages that make it
very hard for people to migrate off Emacs, to other tools, ever.

Whatever IDE or editor I work in, I still use Emacs and Magit for Git
interaction. Maybe that as perspective.

------
celeritascelery
The biggest thing that I see as missing right off the bat is the popup. That
lets you execute anything very fast. Having to use the Command Palette to run
commands really breaks that flow.

~~~
kahole
The commands in the pallete can be triggered by a single key-press (indicated
to the left of the item). This makes it only visually different from Magit.

Its not perfect, but close your eyes and its the same sequence of keys to
triger an action.

------
thom
Good start! Looks like it's still missing a lot of stuff I use daily, like
staging chunks, ediff etc. I can actually imagine in 10 years that VSCode is
going to be impossible to ignore even for die-hard Emacs users, so I do hope
people keep iterating on this stuff, and Microsoft on the platform underneath
it all.

~~~
dmortin
The strength of emacs is that once you can program it it's extremely easy to
write extensions for it, even for one off tasks, because it's so quick and
easy.

Compared to this in vscode writing extensions is much more convoluted. You
wouldn't create a new vscode extension for a 1 hour task, for example, while
with emacs it's trivial to write some small code which can help you with your
current task. I often do.

~~~
thom
Is it that heavyweight? There’s nothing akin to just pasting something into
your .emacs, or even a scratch buffer? I admit I have looked around with no
luck.

Doesn’t seem like that’s improbable over the product’s lifetime though, if
there’s enough demand.

------
kstrauser
That's amazing! After using Emacs for years, I switched to VS Code. Magit was
one one of the things I really, _really_ missed from Emacs and I've never
found anything remotely as nice. I'll definitely give this a try.

~~~
rgrau
Die hard emacs user here (but looking sometimes into vscode). Which things you
get from vscode that couldn't get in emacs? Are you definitely set?

~~~
kstrauser
I've made the full switch. I still love Emacs, and if VS Code suddenly
disappeared I'd switch right back. That said:

VSC looks and feels like a Mac app. Keyboard shortcuts to system services work
the same there as in any other app. Emacs doesn't, however much time I spent
trying to get it to do so. It also feels faster in a lot of ways because slow
operations usually don't block UI updates.

VSC is _way_ more popular lately, and it's extendable by people who don't want
to learn elisp. I personally don't mind elisp at all, but I've come to accept
that this is the minority position. So, what's that mean for VSC? It has a
ludicrous number of packages / themes / etc., installable from the builtin
package manager (that everyone actually _uses_ ; no more fetching code from
some guy's website because he's politically opposed to the idea of a package
manager), that actually work out of the box and are configurable through a GUI
(or JSON if you want to commit the settings into source control).

I love Emacs, VSC is much better at editing Python than I've ever been able to
configure Emacs to be. Linters and formatters are well supported and Just
Work.

Here's the majority of my main settings.json file:

    
    
      {
          "files.trimTrailingWhitespace": true,
          "[python]": {"editor.rulers": [99]},
          "python.formatting.provider": "black",
          "python.formatting.blackArgs": ["--line-length", "99"],
          "python.linting.flake8Args": ["--max-line-length", "99"],
          "workbench.colorTheme": "Dracula",
          "editor.fontSize": 13,
          "editor.fontWeight": "400",
          "editor.fontFamily": "Fira Code",
          "editor.fontLigatures": true,
          "git.enableCommitSigning": true,
          "workbench.iconTheme": "material-icon-theme",
          "editor.formatOnSave": true
      }
    

It's clearly not as configurable as init.el, but look how easy it is to change
the theme or font size, and to add vertical rulers, and to configure font
ligatures. As it turns out, I would much rather have settings be that simple
than to have a Turing-complete language for computing the config at runtime.
Others will disagree, _and that 's OK_. But for me, it gets rid of one more
massive excuse for screwing around with my editor config instead of writing
code.

------
jcagalawan
I’ve been using Magit inside a VSCode terminal for a couple weeks, this is a
great alternative!

------
earenndil
I tried magit briefly, but found it unusably slow. Is this different?

