tarsius

But that still doesn't help explain its benefits to someone who hasn't tried it. For the crowdfunding campaign that I ran earlier this year I wrote a few articles. For those unfamiliar with Magit I would recommend [2] and the more visual [3].

[1] https://en.wikipedia.org/wiki/Text-based_user_interface [2] https://emacsair.me/2017/09/01/the-magical-git-interface/#st... [3] https://emacsair.me/2017/09/01/magit-walk-through/#start

"I would like to thank [Marius] and the maintainers who came later, for I would not even have known that I needed something like Magit had they not laid the groundwork in the early days of Git."

Not trying to undersell my own work - elsewhere I also write:

"Despite all this, it would be wrong to assume that Magit started out with a predefined set of interface concepts and abstractions, and all that was left to be done was incrementally filling in the gaps."

Oh, and thanks for you contribution.

But at some point I just had to launch instead of continuing to hope I would eventually get around to launching the perfect campaign. I did however make an effort to give non-Emacs a better glimpse into how Magit works using a few articles listed at [1]. You might also want to check out some of the screencasts that were created by users [2].

[1] https://emacsair.me/2017/09/01/campaign-articles/#start

[2] https://www.youtube.com/watch?v=rzQEIRRJ2T0 https://magit.vc/screencasts

If that is too short or fast for you; a few older and generally longer videos are listed at https://magit.vc/screencasts.

Magit is a text-based Git user interface that puts an unmatched focus on streamlining workflows. Commands are invoked using short mnemonic key sequences that take the cursor’s position in the highly actionable interface into account to provide context-sensitive behavior.

With Magit you can do nearly everything that you can do when using Git on the command-line, but at greater speed and while taking advantage of advanced features that previously seemed too daunting to use on a daily basis. Many users will find that by using Magit they can become more effective Git user.

---

To the moderators:

I have read the rules. Because user submitted stories about Magit have been penalized in the recent past, I am adding this comment.

This article describes the current version of Magit, which can be downloaded and tried out as required by the rules. So I feel justified in submitting this even though the "show hn" rules state the a "fundraiser can't be tried out". The fundraiser can't, but the software this article is about can. This is how one user put it: "An inverse Kickstarter; feels as if the product is already out and pledging started after."

---

The campaign is already fully funded. However, I also tried to reach new (non-Emacs) users and - according to the sparse data available to me - that did not succeed. I hope that this submission can change that. (And of course I also don't mind if a few of those potential users make a contribution.)

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!

[1] https://emacsair.me/2017/09/01/magit-walk-through/#start [2] https://emacsair.me/2017/09/01/the-magical-git-interface/#st...

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.

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 ;-)

[1] https://news.ycombinator.com/item?id=14819256 [2] http://www.paulgraham.com/avg.html

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.

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/

It's important to note that when Richard said that Magit should be "part of Emacs", that really meant "part of GNU Elpa and/or GNU Emacs". If Magit is just made part of Elpa (which I believe is all that Richard wants), then that doesn't change much. We get protection at the cost of the assignment overhead.

But I already wanted to add parts of Magit to Emacs itself anyway. Low-level libraries that are useful beyond Magit itself, and which would benefit from being built-in. That includes some existing ui libraries but also new libraries I intend to write to replace old abstractions used in Magit, such as a file-handler for Git blobs and trees. Magit would benefit if other Git related packages used those, instead of everyone reinventing the wheel.

Once some code is part of Emacs itself it will be more difficult to change than if it were living in a separate repository. On the bright side, that would likely motivate me to write tools to make that process less painful.

https://github.com/magnars/dash.el

> All the Elpa packages are hosted on a Savannah instance.

That's the "publishing repository". You have to push there for a new version of your package to be published on GNU Elpa. But for most packages development happens elsewhere, and in most cases "elsewhere" is Github. Emacs maintainers sometimes commit directly in the Elpa repository (and package maintainers are expected to deal with the consequences, such as "two diverging mainlines"), but development happens elsewhere.

The FSF explicitly allows that.

> The assignment contract we normally use has a clause that permits you to use your code in proprietary programs [...] Although we believe that proprietary software is wrong, we include this clause because it would serve no purpose to ask you to promise not to do it. You're giving us a gift in the first place.

http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyrig...

Some statistics on that: https://emacsmirror.net/stats/licenses.html.

No, we would continue to use Github for the foreseeable future. If a FSF hosted Gitlab/Gitea/... instance came to be, then we would likely switch to that.

Also I am not exactly a fan of either the git forge or the mailing list work-flow. So I plan to add "competitive collaboration tools" to Magit that allow a project to continue to use either back-end while also allowing all or some contributors to use collaboration work-flows that are more tightly integrated with the development and version-control work-flows. https://github.com/magit/magit/issues/2972

The primary downsides of assigning copyright to the FSF that I see is the "waiting for papers to be signed" part and that some potential contributors will no longer be able to / be willing to contribute.

- What's new in Magit 2.x https://news.ycombinator.com/item?id=9936095

- Using Emacs and Git with Magit 2.1 https://news.ycombinator.com/item?id=9873237

- Magit 2.1.0, first major release in two and a half years, is out https://news.ycombinator.com/item?id=9817392

Another reason why the default theme (both in it's light and dark variant) are a bit ugly is that they should work even for users who have customized individual faces. Sticking with gray backgrounds seems like a safe bet.

This is for the benefit of other users (since you have probably already found these resources):

- Release notes: https://raw.githubusercontent.com/magit/magit/master/Documen...

- Update instructions: http://magit.vc/manual/magit/Installation.html

- Homepage: http://magit.vc