The support I received during the last three weeks has been phenomenal! Thanks again! The only disappointment was that the campaign did not get a lot of press outside the Emacs community, which was a bit frustrating because I published a lot of the articles that are intended for potential users who are not Emacs users.
Until now that is - please have a look [1]. I found it quite challenging to explain why someone who is not familiar with Emacs would want to use Magit even though the majority of those who have given it a chance swear by it. It's a bit like explaining to someone who has only every used GUIs, why the command-line can be an empowering interface. But I think I did a fairly good job at [2].
Also, please excuse the crappy video - the Magit campaign might be the Kickstarter campaign with the least polished video to ever succeed ;-) Luckily a few users have created more informative video tutorials in the past [3].
Would it be possible to do a special distribution for non emacs users? I'm thinking of one download with emacs + magit + CUA mode by default + run magit-status on startup (or whatever else would be appropriate).
So it looks like a standalone git client rather than emacs.
I'm an emacs user, so I would never use this, but it's just a thought.
I intend to make Magit usable from the command-line, so `magit diff ...` would be similar to `git diff ...` except that the output would be "actionable", i.e. you can use `s` to stage, `RET` to visit the file/blob [edit: eventually even in an editor other than Emacs] etc. And `q` to return to the command line.
Packaging that up in a fail-safe fashion is a different story, I would like to do that too, but I expect it will be a lot of work and would certainly appreciate help with that. (There are some projects like Lispbox, which might give such an effort a head start.)
At least in the beginning I think "mostly fail-safe" installation instructions will have to do.
Magit is really an incredible piece of work. Thanks so much for it. I mean, I already use emacs, but I feel it would be a legitimate reason to switch to emacs, or even to use emacs just when dealing with Git operations.
This is, by far, my primary complaint about Kickstarter. They insist on sending me emails with "Things we like on Kickstarter". It is, generally speaking, full of absolutely irrelevant projects in the context of someone with a history on KS indicating I am only interested in technology projects.
It is truly infuriating because it always leads to exactly what you said: I had no idea project x was on KS.
I don't know what it is. Some kind of an internal cult. Or is it incompetence? They have my entire history on their site spanning years of supporting projects. Yet they think I might find campaigns about bow-ties and butterflies interesting? Unbelievable.
I wonder how much better campaigns could do if KS actually got their shit together?
Fundraisers are penalized on HN because they don't fit the site mandate. There are always exceptions though. If we had known about this one we might have made an exception for it.
Ah, didn't know about this. It was a bit frustrating to see 15 attempts by happy Magit users to let HN know about the campaign fail miserably. Especially because a few weeks earlier "Emacs and Magit" [1] easily made it to #1. So when this thread at least managed to stay on the front page I figured that drama and success sell, trying to interest potential users in a tool that has more to offer than meets the eye, not so much.
By the way, this thread took a huge dive at some point - was that due to some manual penalty?
And now for something completely different: It just occurred to me that Magit's success is partially due to the use of Lisp, for reasons similar to those described in "Beating the Averages" [2]. Just thought that would be worth mentioning to give this more relevance to the HN crowd ;-)
Personally I figured that the words Emacs and Kickstarter in the same headline would induce lots of surprise with HNers. Alas, I didn't know about the penalty. Its existence is obvious in retrospect, though.
If you like Helm, check out Ivy, Counsel, and Swiper.[1] They do many of the things that Helm does, but are a lot faster, less buggy, and have a less unorthodox UI.
Also check out Hydra (by the same author).[2] That's really revolutionized my Emacs experience recently. It's customizable menu system you can add anywhere. I've put all those Emacs functions I keep forgetting exist in to it and now they're all at my fingertips.
I've tried twice to switch from helm (especially helm-projectile-grep) to the ivy ecosystem and I found the way that helm invokes the search tools to result in a much faster experience, and saw no reason to switch.
spacemacs has a notion of transient states with menu systems like that that is a set of hydra menus. something like `spc w .` to get into a window transient state that shows you this menu: https://i.imgur.com/2VADwd9.png
Hydra itself actually has a ton of really good examples here: [1]
But really the best place to start is with the hydra docs: [2] which not only has examples but detailed explanations of them too.
Regarding my own hydras, they're not quite ready for prime time. But when they are, I'll be posting them to r/emacs.[3] In the meantime, you can search there for hydras too: [4]
I love Helm. Tab completion is fine when you know exactly what you want and the point is just to save some keystrokes. When completion involves some exploration is where Helm shines and is way better than tab completion, as it doesn't requires knowing the order of parts of the string to complete and support regexps.
When exploring some large code base, or trying to get at a rarely used emacs function or variable whose name you don't remember exactly (but it's about foo and bar for sure) there is definitely this fuzzy discovery element. And then the Helm approach is a blessing. Helm is completion + efficient exploration and discovery.
I like and appreciate org mode a lot, but I could live without and not notice. Emacs is more my lispy scratchpad with OS batteries (I mean bindat, sockets, comint, eshell, <lang>-mode, ...)
Org-mode, has a huge amount of functionality in it. One response to that is that yes, it's amazing, a very impressive ecosystem. Another response is that the lack of single-purpose and modularity is maddening; it's tempting to say it's against the unix design philosophy etc.
Of course, that's also the old joke about emacs. Personally, as I got more heavily involved in software development, I wound my org-mode usage down to just outlining and syntax-highlighted source code blocks.
(A bit of an aside) This represents an interesting 1-person 'business model': make yourself useful (and known to be useful) working on an open source project. Once established, use kickstarter to gain some full/part-time funding. The amount of pre-kickstarter work involved to get there obviously wouldn't make a good business case in purely utilitarian terms, but it seems like an appealing way to have a chance at getting paid to do some good work.
During the past few months I have seen a lot of blog posts by burned out maintainers of open source software. One complaint was that companies expect to be treated as customers without actually paying anything.
My problem is that I am one step further removed from the money - I write "end-user free software", that's even harder to get companies to pay for than an open source library. The Magit users among a company's employees might be among those wasting the least time on version control and make fewer costly mistakes than others, but while that benefits the employer it is not something that is being measured.
So the money has to come from the developers themselves. I am very grateful that so many of them have decided to back my campaign. I also think that the Emacs community is being very nice with its maintainers. The vast majority of users are very respectful when they need your help and they are generally a nice bunch.
I don't know if a second campaign in one years time would succeed though - so it's unclear whether this could become a successful "1-person business model". I certainly hope it does - not just for me. It would be nice if fewer authors of unique free software projects had to throw in the towel eventually and move on writing "real world software" - you know things that scale.
I actually did try to get some companies to pay for my work. I hoped that Github, Gitlab, or Atlassian would see this as an opportunity to gain some goodwill in the free software world, but that didn't work out unfortunately.
The Gitlab CEO actually replied within a few hours and seemed like a nice guy (after sending my message but before getting his rejection I had actually booked a flight to go see him at a meetup), but he was not interested in sponsoring my work. Atlassian send me a canned response, and Github did not respond at all.
Nor did its CEO who actually is (was?) an Emacs users who had forked Magit at one point. I can't really blame him for that, the message probably was just drowned in a lot of other email.
But I would have hoped that those companies would show some interest. Maybe now that its users have shown with their wallets that they believe in Magit, maybe now that changes. If you work for one of these companies, or a less known competitor, and have anything to say in such matters, you are certainly welcome to support me now!
Yes it's inevitably a pretty hard row to hoe. It's innate to capitalism that people without money as their ideological &/or motivational foundation are rarely going to be in positions of influence. So it will be hard to convince the denatured creatures that are positioned as real influencers to expend their precioussss where they don't need to. And they don't need to in this case.
The bright side is that our world is not (yet) entirely comprised of the morally eviscerated, so, as you say, money for many widely useful things will have to come from 'the developers themselves'. It may not form a sustainable business model, but the temporary expedient is better than nothing.
Any recommendation for a good tutorial or introduction article about magit
i use sourcetree, and i like it a lot, but with all the positive talk about magit, i need to try it
i now only use emacs for org-mode and this mode is also by far the best personal todo list i used (i.e. if you dont need any social, sharing features found in web todos, org-mode is the best there is) .. so i know emacs can be very good
I use eshell and tramp so that all my dev work is from in Emacs. It also meant that git was kinda ugly in the eshell, so that made the change to always use magit kind of easy.
In general, things just work as expected. Bind "C-x g" (or whatever) to open the status window, and "s" will stage changes. "c" will bring up a window asking if you want to commit. "k" will kill whatever the point is at. Tab will expand changes, and you can highlight then with a region to stage just part. (Or kill to discard part.).
I've backed the Kickstarter too. I use Magit a lot while making money programming (and even more for hobby projects), so it's only fair to donate. Thank you 'tarsius for all the good work!
I was happy to back this and glad to see it get fully funded. I hope others will still contribute as the author will be able to work on Magit for longer.
I still think the best Git plugin for Atom is https://atom.io/packages/atomatigit-robdel12 It keeps the general spirit of magit which... is probably the best git client out there. Fugitive is a close second.
Seems pretty difficult to use, almost on the same level as trying to learn to use vim/emacs on 2017, somehow i expected a "poweful (G)UI" rather than a text-based one. Anyone has a good recommendation for a good GUI for GIT, GIT-GUI its a really confusing and jetbrains integrations felt like someone with heavy background on cvs/svn made the interface.
The question is: How well do you know git? If you know it well, magit should be pretty intuitive. If you don't know git, you might be overwhelmed by all the strange names and options. But they're all just git -- all exposed for you to use.
What is difficult about it? I don't mean that combatively. Genuinely curious. I'd think a toolbar might help some folks, but I also expect some folks need a different interface.
From the example of kickstarter, it seems completely undiscoverable -- things just keep happening and popping up and down, with no obvious indication of how, or why, those things were selected.
It's a demo which I'm sure appeals to emacs users, who are the target, but I couldn't imagine using it as a non-emacs user. I previously tried learning emacs to use OrgMode, and gave up after a couple of days when I failed to master even basic text editing skills.
It's actually very discoverable. The video lacked the sidebar showing the keypresses, though.
Generally, each time you press a key that is part of a sequence, you get a pop-up explaining what further keys are available. So for instance, I opened magit (M-x magit-status) on a project and pressed ? (for help):
This is my original point, tbh i didn't know about magit before this post, when i first opened the link and find out about it somehow i expected a GUI rather than a text-based app, m sure vim/emacs fans are excited about it but to me, this type of UIs (text-based) feel old and clunky. it's like we were still using norton/midnight commander for handling our files.
Magit is definitely different enough from both your conventional GUI and command-line interface to make it hard to immediately see its benefits, which is why I did not only post some commented screenshots [1] (which may fail to impress), but also a text [2] which explains in what ways Magit differs from GUIs and command-line interfaces and what sort of benefits it draws from that.
A reason why it might actually be an advantage that the interface is "text based" is that the thing the tool interacts with is also text [3]. The primary difference to git is that the "output" is "actionable", the primary difference to GUIs is that every feature of git can be exposed quite naturally.
[3] And a major advantage of that is that the barrier between writing the code and thinking of it in terms of change sets starts to break down.
The point of this kind of UI is that they become an extension of yourself. Saying these UI are old and clunky is exactly like saying a keyboard is old and clunky.
Sometimes 2-clicks can be faster than 2x 3-key combo just to make a feature work and also keyboards are old and clunky, ask any k-12 kid today and they will type faster on touch keyboard than a mechanical cherry-mx powered one. People still using text-based only IDEs for productivity are just prolonging the inevitable.
Only when training is lacking. And I don't mean this in a derogatory message, either. People that are trained with a keyboard are pretty much guaranteed to be faster than folks that have only learned to work with a mouse. Discover, though, will be much much faster with an exploratory interface. To that end, the mouse will lead to faster discovery in most cases.
It is powerful, in that it exposes everything of git. However, I doubt most people use most of that. I've found few, for example, know all the flags you can pass log. Magit actually helps fill them with tab completion on path names and such.
Just read the getting started guide, and you are set for most use cases.
It could be that I would only need 10% of this knowledge, I get it. I really wasn't intending to "punish" it, simply stating that over 100 pages of detailed docs for a Git UI can be intimidating.
Diff's are the only thing I don't like in magit. Well, it's not really magit per se, as it uses another emacs plugins for that.
Staging/unstaging/reverting (specially when you don't want to do that for a whole file but for a chunk) in magit however is so far ahead of every other git interface I've seen that it's not even funny.
Used to use Atlassian's SourceTree, major slowdowns and lack of a native merge conflict resolution tool had us pleasantly surprised when we first heard of GitKraken: https://www.gitkraken.com/
A year later after discovering Kraken, we've now migrated to it and the developer experience has been great.
SourceTree is a great example for how to destroy a software. The first version was great and showed a good understanding of how to work with git. Then it seems other devs took over and just messed it up completely. Pretty sad.
Best GUI for Mac and they also have a Windows client as well now, just makes life easier and repos easier to manage especially when you have merge conflicts!
The support I received during the last three weeks has been phenomenal! Thanks again! The only disappointment was that the campaign did not get a lot of press outside the Emacs community, which was a bit frustrating because I published a lot of the articles that are intended for potential users who are not Emacs users.
Until now that is - please have a look [1]. I found it quite challenging to explain why someone who is not familiar with Emacs would want to use Magit even though the majority of those who have given it a chance swear by it. It's a bit like explaining to someone who has only every used GUIs, why the command-line can be an empowering interface. But I think I did a fairly good job at [2].
Also, please excuse the crappy video - the Magit campaign might be the Kickstarter campaign with the least polished video to ever succeed ;-) Luckily a few users have created more informative video tutorials in the past [3].
[1] https://emacsair.me/2017/09/01/campaign-articles/ [2] https://emacsair.me/2017/09/01/the-magical-git-interface/#st... [3] https://magit.vc/screencasts/