Git and GitHub Integration Comes to Atom | Hacker News Reader

Git and GitHub Integration Comes to Atom

blog.atom.io

276 pointsjohdirr106 comments

This has been in the works for a long time. There's a great interview with Atom's lead maintainer, Nathan Sobo, in a Feb 2017 Changelog podcast episode where he talks about the evolution of this feature in depth. https://changelog.com/podcast/241

Just today the author of the "merge-conflicts" package for Atom emphasized that his plugin is depcrecated because Atom 1.8 will have that feature included by default.

https://github.com/smashwilson/merge-conflicts/commit/f61950...

https://github.com/smashwilson/merge-conflicts/blob/master/d...

Yeah, he's now a developer on Atom and worked on the GitHub package...

Bundling these features by default is bad for Atom. It changes Atom from an editor to an advertisement. Maybe Github dwarfs the competition but boxing them out of the editor is unnecessary. This smells like bundling IE with Windows 98.

On the other hand this will Github an incentive to keep on improving Atom. Maybe someone has finally figured out how to monetize an editor. I hope so, cause the current ecosystem of editors is a mess of half baked solutions.

Monetizing an editor was a solved problem 40 years ago.

but stopped working maybe 20 years ago.

Why use one of those half baked solutions when vim already exists?

Not everyone is productive using vim.

I've never actually seen anyone use vim more efficiently than the average programmer can use Sublime Text or Atom with no skill and a mouse pointer. It's just too much required engagement to do things as simple as move to a specific point on the screen or uncomment/indent a bunch of lines of code. Installing plugins is tedious, tabs/buffers/windows are clunky, and memorizing key commands for plugins (like a file tree view) is required before using it, not gradually learned using context menus as a crutch.

You are obviously entitled to your opinion and it might be that you've only seen people who are still learning to use vim, but to give little perspective from someone who has been using for little over two years.

Movement:

Moving around is a hassle at first, most people insist using arrows instead of hjkl, but even thous are slow and tedious. You get much more mileage from using w, e and b for jumping between words, but even thous get slow after a while and recently I've been using the f and t commands to Find and jump To places (characters) I want to. Obviously it requires some time to learn and I am by no means perfect, but I dare to say it is faster than scrolling and pointing with a mouse.

Plugins:

I don't really see how installing plugins is tedious, you just slap one of the managers into your ~/.vim/autoload (I use pathogen) and then rest you just clone to ~/.vim/bundle. Vim doesn't have build in plugin browser and one click install, like Atom does, but at least to me that is not a problem. Maybe it's because I don't use that many plugins, who knows.

Tabs/buffers:

These do take some time to get used to, but I wouldn't say they are any more clunky than your average editors tabs.

Memorizing commands:

At first it seems like insurmountable task since almost every key is a command and as you mentioned most plugins have their own commands, but truth is you don't need most of them to get started and as you use the tool (or at least thats how it was with me) you Google how to do something tedious faster and there is almost always a better method. As for the "file tree view", I don't know what that plugin is, but I can guess and I used something called NERDTree at start, but vim's build in :find command is pretty powerful at just finding what you need and now I use fzf which makes finding files even faster.

Over all I get why you might dislike vim even without trying it (since most vim users constantly push their shitty editor (and dont get me wrong vim is shit, but it's least shit editor I've yet found)), but I suggest you try using it on a side project and see if you like it, don't install any plugins at first just try reading the documentation and making changes to the config as you go along. I bet you'd be surprised how much you'd enjoy it.

I've tried and learned vim and I'm very capable of navigating with it (I don't use marks but I use about everything else) and it is precisely good at one thing: being an editor. If you try to make it an IDE, I believe you're just using a bad IDE. It is only effective for me as a very lightweight editor for quickly making simple edits to a file.

Why don't I like it as an IDE?

* Second hand auto complete

* Second hand project management

* No debugger

These are actually to me huge features and the third party support for each of them exists but doesn't touch the quality of implementation in a dedicated IDE. Not to mention it adds hours of extra work to getting started in an environment you don't already have configured.

And frankly, you don't have to learn vim to recognize this.

If you need IDE then go with IDE. There are many programming tasks and languages that gain no benefit from IDE-ish things.

For me auto complete works just fine and I don't know what project management means.

The critical feature of auto complete is discovery, not saving a couple of seconds of typing (its always too slow for that anyways). Even if a plugin exists (which I dont think one does) which has auto complete with in line documentation and method/property details (pretty crucial to discovery), theres not a chance in hell it succeeds in making it presentable in the terminal.

I think VSCode/atom fit in the nice space where you don't want huge, intensive projects, but you do want to do some real programming (aka you'll need this discovery and a good debugger).

>real programming

Ok :)

Language servers could solve this problem and let editors hook into a deeper source of understanding of what they're editing, without building in the functionality themselves.

[1] Intro blog post: https://code.visualstudio.com/blogs/2016/06/27/common-langua...

[2] http://langserver.org/ - has a table of current implementations

I used vim for 3 years until Sublime Text came out and found I get work done much faster with it. I used the jump feature (forgot what it's called, similar to AceJump on emacs), position stacks, search commands, etc. I installed and learned NERDTree (that's the name) and a buffer management plugin, but they took hours to get used to while editing and many more hours to configure my .vimrc to be somewhat sane. ST came along, and with some plugins, I was able to migrate very smoothly and was introduced to some new editing methods, like multicursors and the wonderful Ctrl-Shift-Up/Down commands for moving lines. No more sequences of characters to perform a common task!

If ST was open source, there would be no need for a competing GUI text editor IMO.

If you feel like remembering vim's commands is a chore then it is not for you. For me they are reaction, I don't even think about chaining then together to accomplish my task.

As for plugins I do not see the need for NERDTree or buffer management. At least for me searching (:find for files and :b for buffers) works perfectly fine and I dare say better/faster than file tree navigation.

Multicursor is fun, but it can be achieved with a plugin in vim also, but I'd just make a macro for it.

Moving lines up and down can be easily done with dd and p, so I don't see the issue here either.

>competing GUI text editor

There might be your problem for me using vim with tmux makes my life so much simpler than using gVim or other GUI editors.

You just made my day!

Didn't knew Ctrl-Shift-Up/Down how can I've been coding without!

None of Vim and Sublime Text has "Github integration" or "deploy to Azure" or "send feedback to Twitter" type of features. They are plain, simple, useful editors which get the job done.

Sure, I think we can all agree that bloated features like this are undesirable. But there are many options for editors that don't have these features, gladly.

Installing the bundle as a plugin would change none of that. Editors are half-backed because the proof of concept is easy and the fully realized app is hard. Atom has some good things going for it (minus performance) and this Github bundle is probably awesome. But it's not good product management to pick favorites like they did.

More like a mess of overbaked solutions.

I find bundling Git support with Atom is a requirement, VSCode does it.

Of course, VSCode also supports TFS, Perforce, and Mercurial via extensions:

https://marketplace.visualstudio.com/search?target=VSCode&ca... Providers

There are community-provided atom packages for all/most of the providers you listed. The point isn't one editor versus another. The point is that Atom should remain plausibly neutral about Github (which is separate from Git or Mercurial or whatever).

An analogy would be if VSCode shipped with a fancy CodePlex dashboard by default (I know CodePlex is dead). There's an obvious incentive for them to pick sides but it's not in the best interest of the people using the editor nor the editor itself.

> An analogy would be if VSCode shipped with a fancy CodePlex dashboard by default

Or, for example, a "Deploy to Azure" button...

Git support is different than a Github bundle. Github is different than Git.

But atom is made by github, right? Not to justify their choice but you can see from a company perspective how it surely aligns with their goals (increase github market share).

I wonder what the market share is and if they're actively seeking it at this point.

I wouldn't say that they necessarily want to increase their market share at this point (but that may have been the original intent). Now it is probably more about retaining as many users as possible by offering more or more convenient services than their competitors.

It would be quite fine as a plugin. I'm using fossil for instance so care little about git integration. Atom is already bloated and slow as it is, but then again it's their call to bundle whatever they want because I'm not going to use it anyway.

It's a tricky question. Visual Studio Code (probably Atom's chief rival at the moment) has git support right out of the box, so there's a plausible argument that it's a must-have feature. GitHub is less clear.

As long as they make it easy to hook up to a competing repository solution, like Gitlab, I'm fine with it.

who cares what it smells like.. if you use github, why would you prefer github to "stay pure" as you've put it?

I couldn't agree more. Thanks for saying so.

I've always considered Atom to be an advertisement for GitHub. The branding is unmistakable.

to me it smells more like adding a "deploy to Azure" button to Visual Studio.

(It's had that button since Azure started)

Thing is, nobody is going to download Atom, see that the GitHub support is built in and say 'oh! Now we're going to have to migrate the team to GitHub!'.

VS Code has a smiley you can use to post feedback to Twitter. It makes the status bar look like a juvenile bulletin board. It's already been reported as an issue and people want it out of the way. That alone made me deinstall it after less than five minutes.

Really? You gave up on an editor because of a smiley face icon? And you call the editor juvenile?

I seriously have no words. That is the pettiest thing I've ever seen in my life.

I might just have to fork this and wire it up to the GitLab API...

https://github.com/LestaD/atom-gitlab/issues/8

For what it's worth the plugin is using GitHub's GraphQL API.

GitLab is considering GraphQL.

https://gitlab.com/gitlab-org/gitlab-ce/issues/22753

It won't have much of an impact on a fork currently. It looks like the API is barely being used.

This looks like it's going to be neat! But why does it come bundled by default [1], instead of an optional package?

[1] https://atom.io/packages/github

Because Atom was created by Github I persume.

So they should ship it as a promotional tool?

You can make the argument that they want to encourage you to submit patches to the project which is on github.

It's kinda the same deal with GNU Emacs which bundles a whole bunch of stuff that is directly related to the GNU project.

Really at the end of the day it's a fork away to shipping with SVN,CVS,mercurial,gitlab or whatever.

Many of these features already exist as an optional package.

Lots of people use GitHub anyway

Disable it if you don't like it.

If this means that PR comments can now be displayed in-line from the editor, I am switching from Sublime Text. I bought ST3 outright, but I'll switch in a heartbeat to display comments and feedback.

Try vscode, I think you'll be pleasantly surprised that it's in fact now leaps and bounds ahead of sublime.

Does vscode run on Linux?

Yes.

Just a note. Sublime still has its niches above VSCode. Sublime still can handle much larger files, and is a lot faster overall.

That being said, I switched from Sublime to VSCode a year ago

reply Just a note. Sublime still has its niches above VSCode. Sublime still can handle much larger files, and is a lot faster overall.

That being said, I switched from Sublime to VSCode a year ago, and VSCode is far ahead of Atom when it comes to performance.

They have a more technical run down of how this works on their engineering blog: https://githubengineering.com/integrating-git-in-atom/

This looks like a fantastic development, but I worry about performance. Atom is already pretty sluggish, I would rather see performance upgrades before new features. Maybe they're not correlated.

Especially with the rapid adoption VSCode is seeing. This seems kind of like the wrong move at the wrong time for Atom.

Performance has been a key focus of the last few releases. 1.17, the stable release also being released today, has a major jump: http://blog.atom.io/2017/04/18/improving-startup-time.html

Thanks; I'll upgrade

Has memory usage also been a focus? I got scared off from exploring Atom a month ago by https://news.ycombinator.com/item?id=14141855

I think that guy's just exaggerating, or using a buggy plugin. I'm running Atom 1.16 in Windows right now, 2 panes with ~6 tabs open and it's sitting at around 25 MB of memory. This is with vim-mode and a python autocomplete plugin running.

You must be overlooking the `Helper` processes. Running a clean install of Atom takes about 400MB memory (macOS Sierra).

I assume this is one of the reasons they decided to add it "natively". Since people are using git/github plugins anyway. Here is the old package: https://atom.io/packages/github Here is the work they did to upgrade the performance: https://githubengineering.com/integrating-git-in-atom/

I just tried it out and the UX is ridiculously broken for me. Whenever I try to focus one of the Git or Github panes, the content of the panes completely vanishes, since I'm unfocusing the file the content was about.

Hey we certainly want to look into this. File an issue at https://github.com/atom/github or send an email to atom@github.com describing it and we will!

Done: https://github.com/atom/github/issues/825

The fix will be in a patch release next week. :)

https://github.com/atom/github/pull/847

It's the first beta. Just open an issue with your system and configuration details.

Hopefully this eventually reaches the level of utility of Magit (https://magit.vc). It's what helped me get over the hump of only using 4 or 5 git commands, and bundles a ton of useful "macros" in a great interface. And of course, it's incredibly customizable because Emacs.

Magit is awesome. It's the one tool that got me using git at all.

As a long time (happy) user of the Git-Plus add on for Atom, I am not sure how I feel about this. Mainly because I use BitBucket for 95% of my projects. I only use GitHub very rarely for public projects that I blog about.

I hope that this won't break existing Git plugins, and won't limit Git functionality for non-Github based repos.

Even though it comes bundled by default, like everything in Atom, you can just disable it as a default package in the settings.

Has this been GH's eventual goal in developing this thing? Playing the long game?

The game has changed over time. They originally intended to charge for Atom. Then it became arguably the best free option, until VS Code came along.

I think a lot of us have moved from Atom/Sublime over to VS Code these days. Seems like lots more momentum and gobs of useful plugins that let me do my work.

I guess this is the IDE crowd? Us vim guys are still raising eyebrows when people say "best free option" :)

More so the "I want debugging and intellisense without the slowness of an IDE" crowd. :)

I've been a vim user for a long time. I switched to Atom despite its slowness because I finally get linter and autocomplete integrations that just work. Those have always been a pain to set up for me in vim, and when you are switching between machines all the time, that quickly becomes tiring.

I don't see a reason to stick with traditional vim for the majority of my work, since most other editors have plugins with a very good coverage of the core vim features/keybindings.

EDIT: Oh yeah, and multicurors. I just remembered that they were also a big part of reason for switching. At least at the time, every implementation of multicursors in vim was broken in a very major way for me.

Re: multicursors, that's what macros are for.

Sure, you can do most things with macros, but I prefer the interactivity of multicursors. With macros I have to carfully plan out how the macro will affect all the different instances where I let the macro run, and if something goes wrong, I have to revert it and try again. With multicursors I also have to do some trial and error, but usually much less since I can immediately see how each step influences the text at all cursor instances, and revert it in a much more granular way.

If I have to do some heavier processing for 100-1000+ lines, I still use macros, but for most cases in my day to day programming multicursors just feel better.

I guess I'd say lowest common denominator. As in install in 5 minutes and writing code with no experience crowd :-)

The price is your soul.

I'm not sure if a stronger focus on git/GitHub is a step into the right direction for Atom users. I'd strongly recommend to provide a choice. Why not other VCSs, why not other platforms?

We get it, Atom is GitHub's pet toy. But never assume it will be forever. Remember Sourceforge and CVS?

There's nothing stopping you from disabling this and installing one of the many quality community git packages. We even list them at the bottom of the launch site! https://github.atom.io

I tried it, because I'm trying to convince a colleague to use markdown and git for a collaborative project. This person lives mainly in the MSword world, so I thought atom might be a good choice. In testing it, I found the git interface was simple for me, having used git for years and therefore knowing what "staged" means. However, the interface will be confusing for my colleague. It would be great if the atom folks could make a 30-second video of the workflow, a bit like Apple has done for taking photos of different types. Failing that, it will be me on the phone with my colleague, telling them what to click and when. I think the atom folks could have done this better. Maybe they should highlight the "next most likely" action at any time.

For nontechnical users Gitbook Editor is a great alternative to this. You don't have to have a gitbook.com account to use it, just dismiss it when you start the app, it also supports Asciidoc which in my mind superior to Markdown for any kind of documentation.

Kind of surprised the integration isn't going in the other direction. Embed the editor experience into Github and not the other way around.

Why wouldn't they wait until it's in the non-beta version. I will probably forget about this by the time it's there.

I can't get into Atom, the load time vs something like sublime is just too slow. Am I doing something wrong in the settings?

Load time of what? opening a file? It is instantaneous other than really large files.

Yes once the program is already open it's pretty snappy. But I like to keep my desktop clean so I close / open it fairly often and it's startup time if just not on par I've found.

RAM you're not using is a waste of money ;)

That's why I make sure to include memory leaks in every program I write :)

The snapshot feature introduced recently makes a big difference to app start-up time.

Since it's Electron I'll give it some slack, but I've switched to VS Code and performance is just so much better than Atom.

Atom with a few extensions installed takes it to a drag. I went through timecop a hundred times to speed it up and finally gave up.

I suffered through the slowness from the start, and it paid off. This is the first beta I've used in a very long time, and the difference between this and the current release version (1.6.x?) is noticeable.

I agree. I upgraded from 1.16 to 1.17 (and 1.18beta), and both feel much more snappy on my Macbook Air. Before that it has felt slow but tolerable and has now gone to barely annoying.

Magit for life

darcsum for life.

They should really separate git and github packages.

Wow. This looks amazing. I have always loved atom's UI. Now, the git and github integrations are really cool too.

This is fantastic, excited to try it out.

Surprised this wasn't done at the start of the birth of Atom.

Atom is dead slow. It sucks. Whose bright idea was to make it in Javascript?

Sublime is around one million times faster and has most of the packages. It's a no brainer.

Reply on news.ycombinator.com