
Git and GitHub Integration Comes to Atom - johdirr
http://blog.atom.io/2017/05/16/git-and-github-integration-comes-to-atom.html
======
simonw
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](https://changelog.com/podcast/241)

------
easychris
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/commit/f61950a81670099fbee51c21443722afbe36041b)

[https://github.com/smashwilson/merge-
conflicts/blob/master/d...](https://github.com/smashwilson/merge-
conflicts/blob/master/docs/announcement.md)

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

------
heygrady
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.

~~~
tschellenbach
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.

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

~~~
vortico
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.

~~~
nextlevelwizard
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.

~~~
vortico
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.

~~~
nextlevelwizard
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.

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

[https://github.com/LestaD/atom-
gitlab/issues/8](https://github.com/LestaD/atom-gitlab/issues/8)

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

~~~
deckar01
GitLab is considering GraphQL.

[https://gitlab.com/gitlab-org/gitlab-
ce/issues/22753](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.

------
niftich
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](https://atom.io/packages/github)

~~~
hdhzy
Because Atom was created by Github I persume.

~~~
robert_foss
So they should ship it as a promotional tool?

~~~
jjrh
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.

------
faitswulff
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.

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

~~~
simplehuman
Does vscode run on Linux?

~~~
chillee
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.

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

------
austenallred
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.

~~~
apetresc
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](http://blog.atom.io/2017/04/18/improving-startup-time.html)

~~~
brlewis
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](https://news.ycombinator.com/item?id=14141855)

~~~
apetresc
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.

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

------
hobofan
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.

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

~~~
hobofan
Done:
[https://github.com/atom/github/issues/825](https://github.com/atom/github/issues/825)

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

[https://github.com/atom/github/pull/847](https://github.com/atom/github/pull/847)

------
Tenobrus
Hopefully this eventually reaches the level of utility of Magit
([https://magit.vc](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.

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

------
cyberferret
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.

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

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

~~~
bdcravens
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.

~~~
tankerdude
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.

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

~~~
hobofan
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.

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

~~~
hobofan
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.

------
rhabarba
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?

~~~
io
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](https://github.atom.io)

------
bluenose69
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.

~~~
type0
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.

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

------
freebs
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.

------
jackdh
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?

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

~~~
jackdh
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.

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

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

------
_binder
Magit for life

~~~
rhabarba
darcsum for life.

------
TheCabin
They should really separate git and github packages.

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

------
emceestork
This is fantastic, excited to try it out.

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

------
warrshrike
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.

