Please help improve Magit
magit.vc
magit.vc
I just got a message from Tarsius because I'm sponsoring him. This is what it says:
"Recently GitHub announced that GitHub Sponsors is going to abruptly stop accepting PayPal payments on February 23, 2023.
"In the three days since, I have already lost a dozen sponsors. If this continues at this rate, I am going to loose over half my sponsors on this platform.
"This is a huge issue for me. These donations are not just a nice extra but how I make a living. I already have to get by with an income that is way below minimal wage, so losing sponsors in great numbers really hurts. I receive about 80% of all donations through Github Sponsors, losing between 50% and 75% of that, would mean I cannot pay my bills anymore.
"If you are currently using PayPal, then please take some time to switch to another payment method, either here on GitHub, or by using one of the many other options donation options."
My personal opinion as a professional developer and one among many donators is that I couldn't survive my work without the help of Magit. It allows me to be really effective and to find new Git tricks.
If you are using Paypal as a payment method in Github, please switch to another way of donating. And if you're not donating, this would be a great time to start.
https://magit.vc/donate - Donate to Magit!
https://www.reddit.com/r/emacs/comments/11cezoq/magit_mainta...
> "Hi folks - Emma from GitHub here. I completely understand PayPal is the payment provider of choice for some people (in fact that’s how many of us made our own sponsorship payments until very recently), but we’re making this change now so that we can ensure that as much investment as possible goes directly to the maintainers of the open source projects you want to support as well as help us scale GitHub Sponsors so it can support the growing number of maintainers that are now depending on it. As pointed out, we are actively reaching out to the people who currently use PayPal to invest in open source with instructions on how to switch if they want to. We hope you do as the Sponsors community really relies on your investments."
I'd guess Microsoft will soon be rolling out their own version of Paypal which will be acceptable, or something like that? Ask the FTC to intervene on anti-competitive practices, maybe.
For anyone else, though: please note that PayPal is cheaper than Stripe, with bulk rates that kick in sooner and support for a special micropayments tier on smaller tickets (though this option isn't quite as good as it used to be; I'm grandfathered in ;P).
Stripe frankly gets away with a lot on price simply due to being the "darling" of developers, who don't necessarily check and often refuse to negotiate no matter the cost to their bottom line (see how expensive people assume Akamai is ;P). I was shocked how much Stripe wanted to charge for AliPay, as an example, as if you work with AliPay Global directly (instead of going through Stripe) the cost is 3% with no flat fee, while Stripe decided to keep their $0.30 "I don't know what I am doing I just want it to work" fee.
Perhaps GitHub have been on the receiving end of PayPal doing dodgy shit once too often, and are now going to do something about it.
I am a bit overwhelmed right now, but will try to provide some background information and answer some questions over the course of this day.
For now, since many of you probably are not Emacs users and might be wondering how this is relevant to you, consider that Magit has inspired some (incomplete) clones, that you might find useful.
See https://github.com/magit/magit/wiki/Inspired-by-Magit for a list of tools inspired by Magit and https://emacsair.me/2017/09/01/magit-for-non-emacs-users/ for some older musings of mine on the matter.
Anyway, I couldn't live without magit. Donated.
Just signed up to be a monthly sponsor, because when push comes to shove - Magit brings me more value than something like Netflix.
I struggle with doing the math on open source software in my head often.
I.e; Netflix is fun, I get to watch nice content! vs This free thing is bloody great, I am so happy its free...oh hang on, someone needs to spend a load of time making it so good.
I want to live in a world where more stuff is free to use for all, but sponsored by the "market", so the amount of effect is maximised, while the economics are maintainable to keeping the impact open to all.
What a tricky problem to solve at scale because of the tragedy of the commons (As in; "I'm sure someone - not me - will be a sponsor for this project")
It is only tricky, if we make it tricky. Basically if one can afford it and really values something, then one should support it. That way all the people, who cannot currently afford to support it, can continue benefitting from it. As a second and much later thought only, one can still look at how much support a project is getting and whether anyone can live on that, maintaining the project.
Often we should ask ourselves: "What if everyone acts like I plan to act?" (basically Kant's version of the golden rule) -- That way it becomes clear, that the project would die, because if everyone thinks "Surely someone else will support it." then obviously no one will support it.
I think there has at least been some shift towards supporting great creators in recent years, but there is still a long wait to go until we:
> [...] live in a world where more stuff is free to use for all, but sponsored by the "market", so the amount of effect is maximised, while the economics are maintainable to keeping the impact open to all.
"That which is common to the greatest number gets the least amount of care. Men pay most attention to what is their own: they care less for what is common."
We have solutions for tragedies of the commons like this: Professional Associations, Unions, and Guilds.
They have the ability to raise funds through their membership fees, and can then spend that money on the common good. Membership can be 'encouraged' by requiring payment for commercial use if the company/it's employees aren't part of the association.
This solution is just not very popular, partly because of aversion to having to pay a % fee of your paycheque, partly because it's arguably "taking open source proprietary".
But if proper open-source is unsustainable, professional associations may yet be better than the alternatives of governments deciding which open source gets funding, or complete commercialisation of open source software.
What we need is a system where we can all pull from a common pool of FOSS donations. For example if my projects were registered and I made commits during a donation cycle, I could receive a fair portion of donation revenue. Something similar to residuals [2]
[1] https://github.com/zloirock/core-js/blob/master/docs/2023-02...
[2] https://en.m.wikipedia.org/wiki/Residual_(entertainment_indu...
Then the remainder can be distributed purely on usage.
With the specific idea of "paid per commit" is that people will abuse it because number of commits (or commits at all) is not a good measurement of if a project is valuable enough to get a portion of the donations.
Someone who has "finished" a project that is used by a lot of people and the maintainer is answering forum threads / issues from people wanting support sounds like a project that should have a portion, but if we only measure commits, they wouldn't in this case.
Another one who only does minor commits that doesn't really move the project forward (or even move the project backwards) just in order to get a portion of the funds without providing value, we probably think shouldn't get a portion. But again, measuring by commits, they would have.
So, difficult problem to solve, and whatever you measure it on, has a chance of being abused.
That would be too gameable... it's too easy to make a million commits that provide zero value.
Thanks for making it for everyone!
> A Git Porcelain inside Emacs
> Magit is a complete text-based user interface to Git. It fills the glaring gap between the Git command-line interface and various GUIs, letting you perform trivial as well as elaborate version control tasks with just a couple of mnemonic key presses. Magit looks like a prettified version of what you get after running a few Git commands but in Magit every bit of visible information is also actionable to an extent that goes far beyond what any Git GUI provides and it takes care of automatically refreshing this output when it becomes outdated. In the background Magit just runs Git commands and if you wish you can see what exactly is being run, making it possible for you to learn the git command-line by using Magit.
The .vc domain was giving me investment vibes, I had no idea what to expect from this link, and was still confused after skimming the page to see if there's info anywhere. Not the best landing page.
This is one of these tiny tools that should continue to exist.
That said, I'm happy with Fugitive. It does the job in a way I'd expect from a vim plugin.
It's just a matter of having the will to do it and putting in the time.
I say this as a huge fan of both editors. They are both so powerful they can do just about anything.
NeoVim is an entirely different beast, and I heard good things about its way of handling plugin development.
Maybe there is an option somewhere in magit to not show diff completely for files with specific file extension or something.
1. Clone <https://chromium.googlesource.com/chromium/src>.
2. Navigate to this directory in Emacs dired.
3. Run magit-status.
4. Observe how long it takes for Emacs to become responsive again. For me it's 28 seconds, while running git status in the terminal takes 6 seconds.
$ git clone https://chromium.googlesource.com/chromium/src Cloning into 'src'... remote: Sending approximately 36.75 GiB ...
So it is not at all surprising, that things get laggy, when you run them on 36.75 GiB. You probably do not want to check out everything at once.
> You probably do not want to check out everything at once.
I do, if I want to compile the project, browse its history and push commits, which is what I'm paid for.
Consider the extra work and data structure representation in the magit buffers in Emacs, that is not done on command line. For example magit makes diffs and chunks of diffs neatly foldable. It also colors things in that foldable content. It also has context knowledge, when you move your point over some diff or chunk and then run another command / Emacs procedure. It probably does some more things I cannot think of right now. Somewhere there is a cost associated with having more than a simple stream of text that is output exactly once, like on command line.
Is it still 5 times as laggy, once the initial magit-status is calculated? Does it recalculate all the things, when you stage a chunk of a diff, or does it profit from having a data representation of the diff in memory?
Sublime Merge is pretty laggy, but in a different way, that's more acceptable to me: it is asynchronous, so when I order Sublime Merge to perform an action on the git repo, I can still interact with the GUI, browsing the list of commits etc.
With Emacs and Magit the problem is that everything you do in Magit blocks the whole Emacs until Magit completes its work. Running magit-status means I can't type anothing in any Emacs buffer, issue Emacs commands, scroll, read through any Emacs buffer etc. for 28 seconds.
Even though GUIs often do more than CLI tools, they actually have more potential to be faster than CLI tools, because they can be asynchronous, whereas CLIs are completely blocking, running in a one-command-at-a-time mode. One example where GUIs are more efficient than CLIs are debuggers. Which demonstrates it can be done.
I see two main issues with Magit when it comes to performance:
1. It's blocking, not asynchronous.
2. It's written in ELisp, which is a fractal of bad decisions performance-wise.
> Is it still 5 times as laggy, once the initial magit-status is calculated?
It is.
In the end, I just stick to Git CLI. It's fast enough, ergonomic enough for the basic usage, and works everywhere. I still wonder people who use multiple IDEs for multiple languages and have to fight different git plugins.
If you don't believe windows process spawingin is slow, try this: clone a git repo with 100+ submodules to your windows box. Now enjoy a nice long coffee break anytime you interact with git. And 5 coffee breaks anytime you interact with git via magit.
This should be potentially be solvable by using libgit2 instead of spawning a bunch of processes.
There has been ongoing work to integrate libgit2 into Magit, but I don't know it's current status, nor whether that integration has made it on to Windows yet.
Is it because of slow git process spawning on Windows, or because magit needs multiple git command invocation to perform an action, or is it "only" slow refresh, I don't know. And honestly, I don't care.
It's a chicken and egg problem. It's too slow, so I don't bother to learn it. And since I didn't learn it, I don't see any benefit in using it that could justify hours or even days of digging for performance tweaks and tricks.
Edit: found my PR. Give it a try, worked wonders for my magit on windows experience https://github.com/magit/magit/pull/4717
Disappointing that your PR was closed without comment.
probably not magit’s fault, and it happens rarely, but it’s one of several problems i cant escape from that give me a sense of dread every time i open emacs.
mostly switched away from emacs as a result
But I have also switched to handling part of it using an around advice, which does work reliably. I've done that about two weeks ago, so changes are that if you update Transient now, you won't ever see that again.
branch: b x
tag: t -f t
Tags aren't meant to be "moved", that's why you need to --force it.
Usually :
- reset - rebase - fetch / pull / push - cherry pick - stash
and then magit-blame, git-timemachine etc.. all work smoothly
But we all have our own usage, what did you try that made magit get stuck ?
As for whether it's Magit or you, I suspect it's git. Git is complicated.
You might like exploring using async-shell-command for these things.
If you like that, you may also like detached.el for command rerunning and command output history.
All this said, Magit is still the best interface to Git I know, and I would regret to see it become unmaintained.
I would've been probably content with a few changes I didn't like, but Tartius' response to my complaint was what set it all aflame. It turned into pointing fingers and name calling pretty quickly.
Then there were useless additions of how pushing worked (the process used to be simpler than it is today, and would do the right thing w/o your intervention). Then Tartius decided to add a new way to diff two branches, where instead of just calling diff, you'd have to set up one local branch as a remote for another local branch (I think, this nonsense still exists).
But the problem was more general than individual points of discomfort. Magit was started being flooded with pointless features that'd get in the way of using the remaining useful parts. I generally believe that a huge chunk of Git is worthless. Eg, I'd never regret completely throwing away everything that has to do with merges, subtree commands, few other things... Magit was very good at focusing on useful features and ignoring the worthless ones. That gave an "opinionated", but a conceptually easier model of the program. Since the takeover, the general direction was to try to express every feature present in Git in Magit, which set it on the path of becoming just as unnecessary complex as the original. Except, for some reason not git-grep, which I had to add myself. Go figure.
It has a lot of very nice overlays to git operations, I tend to use the CLI for most basic operations but the interactive staging/unstaging of magit, as well as its support for rebasing, is absolutely stellar and significantly more convenient than the CLI.
One of the neat bits is, for some operations (e.g. committing, rebasing, ...) if you set emacs as EDITOR and magit has been loaded magit will automatically trigger and take over the buffer instead of leaving you with a basic text buffer.
You don't have to be an Emacs user to use applications written for Emacs. You can use just that application (in this case Magit) and do nothing else in Emacs. That is a perfectly valid use case -- Emacs is closer to a Lisp VM than a text editor.
Thanks - this is exactly the info I was looking for when opening this thread.
I am going to try out Magit on Monday and, if its good (it probably is) will pass it along to some colleagues. I am very comfortable with the git CLI but many of the engineers at my work are not. Anything that can help me shed my "git guy" title will be a win for all involved.
Valid but stupid. Don't carry both an Android and an IPhone. Choose one and get good at it.
There may be valid reasons to only ever have one type of runtime installed, but most people aren't that fuzzy about the compilation target of the programs they use, as long as it runs and is relatively easy to install.
I'd describe it more as a set of text menus for git operations.
It's a text UI, not a graphical one.
You summon magit, navigate the lines you want to stage, hit a key and go back to working. Most of the UI is extremely lean and swift. It's even more powerful than a git video or book to learn things because magit will automatically infer information (if you're on a line of git log timeline, rebase will automatically do it from HEAD to that commit). It will pimp the rebase buffer so that you can change pick to reword / drop / else in one key. It's so obvious you don't even need the manual to discover how to use git. Really one of the nicest UX I know of.
The seamlessness between the command line and the magit UI is another of its strengths.
I don't think I recall a time where magit interfered with the semantics
As a comparison, VSCode git extension adds a side bar with it's own subsections, and buttons with slightly obscure iconography and meaning, would also break usual git workflow (afaik you cannot edit a staged file and restage, it will complain).
Magit, afaik, never does this, it reuse the outlines of git output, it just parses/reuses the local information under the buffer cursor/line and fill in the details for you so everything is one key away. It's like ast interpreter vs bytecode.
For example git-scm belongs to a foundation, which you can donate to and ensures transparency and some structure around spreading contributions. "Donate to some dude" is quite strange to me in comparison.
(Wasn't sure if you were suggesting he's earning 100+k/year)
Let me suggest a thought pattern which might ease your difficulty.
It's hard to imagine a community better positioned than the devs themselves to evolve better solutions to these problems than they are. So the "ways to fund FOSS" they advocate, by for example asking represent some flavor of best solution we've come up with, despite all their flaws.
So do what they ask, to the extent you find their packages useful.
At first I was going to suggest, that someone set up an effective-altruism-for-open-source type of project, that ranks open source projects by how efficiently they can use donated money.
But then I realised also that would fall for the same trap. Why donate to give libcurl higher revenue when you can donate to save people from malnutrition?
(On the other hand, you could argue that the productivity gains afforded by libcurl would allow us (humans) to allocate more resources to victims of malnutrition. So what do I know.)
Individual developers might not care about their company that uses libcurl in 95% of their applications, but might get enough benefit from magit to make it worth their while to donate to it.