i used emacs and magit for 8 years before switching to neovim a few months ago. i’ve switched between the two for a while, but the truth is that emacs is just so much slower than vim, and hangs so often for my usecase (a large go project using eglot and gopls). since i had switched to evil a few years back, going to nvim+lazygit wasn’t a big change and now i don’t have to wait for emacs to block for seconds at a time.
I'm working on a pretty huge go project with lsp and a ton of bells and whistles and haven't had it noticeably lag on anything. Out of curiosity how big were the files/projects in your case? Did you have some other super heavyweight modes going?
I have only noticed magit, or rather Emacs itself, to hang, when the diff contains binary files and very long lines. Magit then tries to create a proper diff buffer showing the diff of those very long lines and chokes. I think there has been some improvement in modern Emacs versions for handling long lines, but things can still get slugish when a whole binary file is a single line. Often people put things in the git tree, that should not be there.
Maybe there is an option somewhere in magit to not show diff completely for files with specific file extension or something.
Have you tried any GUI tool and found a less laggy one?
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?
> Have you tried any GUI tool and found a less laggy one?
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?
I used vi/vim for 25 years before switching to emacs about 10 years ago, and I have not gone back to vim despite emacs occasionally hanging. The advantages that emacs offers over vim for me are just way too great to give up.
I like ve magit, but I often enough find that I end up in a sticky situation that I can't resolve without retreating back to the CLI. I don't know if that's a deficiency in magit or just a matter of me not knowing well enough how to use it. Typically I just call the magit equivalent of whatever git base command I want and helm gets me the rest of the way with setting parameters.
it mostly works super well for me, but sometimes while i’m using magit i manage to get emacs stuck in a weird state where i cant close the minibuffer or enter any commands. mashing c-g or esc in each open split doesnt help, and i end up having to force close.
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.
That's an issue with Transient, a dependency of Magit and also authored by me. It's complicated, but essentially the problem is that post-command-hook is not guaranteed to be run after the command. And the second problem is that I tried working around that for too long (and instead resorted to increasingly sophisticated and desperate heuristics), instead of getting it changed in Emacs. I've done that now, so maybe in Emacs 30.
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.
What kind of stuff are you doing that gets you in a sticky situation, and how are you getting out of it? IME I've generally been able to do most complex things I need with some combination of the stash, rebase, cherry pick/apply and if I've stuffed things up the reflog, all done from within magit.
Curious about that, I think I can count these events on one finger a year (and maybe the absence of direct `git push --tags --force`). For me it's some strange state where creating a branch from a remote doesn't linked the two. That's about it.
Lots of little things, but the last I remember one issue was with modifying the URL of a remote, as well as getting lfs and submodules to sync up properly.
There is also the documented way of running git commands straight from magit [1]. I am leaving this here, in case it may help you with those times that you have to go to the command-line.
Ah that's intriguing, I'm using Magit since forever and had no idea! When I need to do it I like to do it from a regular prompt: I just switch to an actual terminal (i.e. not from Emacs: not an eshell, not an libvterm, not anything like that: just the "real thing"). Then I just hit 'g' (which runs magit-refresh) when I go back to Emacs.
I often get stuck with Magit and have to resort to the CLI to fix things. But what I find is that using the CLI, I only have a vague idea of what I did, whereas if I take the time to understand how to do it with Magit functions, I end up with a clear understanding of what's happened.
I find myself in the opposite situation: I've used magit for so long I don't quite remember how to do things in the CLI. Magit is such muscle memory for me at this point that my git experience has largely become subconscious.
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.
I would change one thing in your answer: it's not for Emacs, it's for anyone. If you haven't tried Magit because you're "not an Emacs user" I would recommend you reconsider. Magit is great, whether or not you use Emacs for other things.
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.
Is that why only use applications written for CPython and not the JVM, .NET CLR, nor V8?
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.
A deceptively simple porcelain on top of git output, embedded into an emacs buffer.
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.
It will also tell you exactly what git command(s) it executed in response to your actions and let you modify actions with shortcuts for git command-line flags, and you can easily run your own git commands.
The seamlessness between the command line and the magit UI is another of its strengths.
It was trendy few years ago, and it's a general idea, it's a bit like jquery progressive enhancement over a webpage, you don't change the whole UX, you just complement/enhance the parts slightly.
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.
I liked magit on Linux, but on Windows it's so slow that it's unusable. Yes, I know it's because git is slower on Windows, but when using git CLI I don't feel the speed difference, while on magit I feel like constantly waiting for it to happen.
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.
I've used Magit on Windows for the past several years and it is noticeablely slower than on Linux (because of the gut implementation on Windows). I completely understand someone choosing a different git front-end because of this. However, it's absolutely useable.
I think it's just because many single Magit commands run multiple git commands behind the scenes in order to collect all the info. So any slowdown in how long it takes to run a single command is multiplied proportionally.
I'm suspicious of this explanation because the views that gather information from multiple commands can generally be configured down to a bare minimum that uses very few (sometimes just one) command. I assume they would have tested this before considering it inexplicably slower.
I experience the same slowness on Windows by using bare magit without any customisation. Can you point to some resources about customisations that could make it fast?
The problem is windows slow process spawning. Magit spawns a lot of processes to achieve it's displays and interactivity. It is a real problem.
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.
"The problem is windows slow process spawning. Magit spawns a lot of processes to achieve it's displays and interactivity. It is a real problem"
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.
No, it's just slow. Every command triggers 1 to 2 seconds waiting. It's enough to break any workflow or any desire to use it. Git command line responds in 100 to 200 ms, which is not a noticeable delay.
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.
As near as I can tell, the guy works on emacs full-time. He's also not
particularly good or clever. With the kind of money he can get through
charity, there's no way he could hire the necessary Windows expertise.
For one thing, he'd probably need to rework Emacs itself at the w32
level.
I was really bothered by this but in the end I found that the slowness was due to conflict resolution when calling git branch. I can find the details if you want, but once I switched the default magit “git branch” call to something dumber it was fast on windows too.
I have a difficult time thinking through how to justify donating to some of these niche libraries. It's not wrong to make a living out of open source of course, but it is slightly strange sometimes to find projects that are super core to internet infra running on shoe strings but then some random dude in SF makes 100k+ / year on some minor library that is syntactic sugar on other stuff. This is not about this person or this project but more of a recent realization. In my company when developers brought up supporting open source, the thing they first remembered is whatever niche npm library they remember seeing a begging readme, when we use so much more important things that could use the help.
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.
Magit isn't exactly a library (although I think it is also that). It's more of an application that happens to be implemented within emacs. There's a number of commercial git clients, so paying for Magit doesn't seem unreasonable to me.
I looked at the project's sponsorship on GitHub, Patreon and OpenCollective. Guessing the average GitHub sponsor donates $3/mo, he's at ~$1,360/mo before fees and taxes. If the GitHub average is $6/mo, that's ~$2,140. The GitHub average would have to be $30/mo to hit $100k/yr.
(Wasn't sure if you were suggesting he's earning 100+k/year)
Magit is by far the best interface for using git and managing git data structures that I have ever used - and I am a vim user! Almost every emacs user I know uses or recommends Magit. It may seem like a "niche library" but in some areas of software development, it's absolutely well-known and considered the gold standard.
It's disheartening to have the top comment on this discussion be a discouragement from individual contributions because the solution is imperfect.
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.
The lesson there should be that projects get funding when they have advocates. The importance of a project to the world means nothing: it’s the importance of the project to people willing to fund it. Your co-workers should feel empowered by this: if some inconsequential software can make money, your co-worker’s advocacy can surely help a piece of business-important software make money :)
This argument is not new: it happens also with regular charities. You could donate to the charity with the highest impact (measured by QALYs per dollar or whatever) but a lot of people donate less efficiently. Sometimes they even get criticised for it. But maybe an inefficient donation is still better than no donation, and should be lauded to encourage more people to donate, however efficiently?
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.)
Magit's call to donate addresses itself to a completely different demographic than the companies that should donate to "super core internet infra" projects.
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.
I've tried it. You can't really port magit from Emacs, its workflow depends entirely on how Emacs works (and this is a good thing, mind you). Neogit just feels awkward to use IMO from a vim perspective.
That said, I'm happy with Fugitive. It does the job in a way I'd expect from a vim plugin.
That's not quite true for original Vim. The developer experience for writing plugins is incomparable; VimL lacks good ways of abstracting and composing behavior, while Emacs Lisp gives you just about everything a modern language should, including sophisticated object system with multimethods and multiple inheritance. The built-in debugger for Elisp is not on the level of JetBrains IDEs, but it provides all the typical functionalities and is GUI-driven, in contrast to Python's pdb or Ruby pry.
NeoVim is an entirely different beast, and I heard good things about its way of handling plugin development.
This reminds me of the recent core-js blog post [1], however Magit is extremely actionable with clear steps to donate or even receive a bill for your employer.
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]
wouldn't this just lead to the projects that are already the most visible (and thus most likely to already receive donations) getting the bulk of the income?
The donors should be able to preallocate a proportion to a list of preferred projects, and the distribution within those preferred projects may or may not be based on usage.
Then the remainder can be distributed purely on usage.
The reason this hasn't quite worked out in practice (although there have been many attempts) is because it is a difficult problem to solve without letting a bunch of abuse through.
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.
"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"
That would be too gameable... it's too easy to make a million commits that provide zero value.
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.
> "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.
Github probably has negotiated better rates. Possibly much better with Stripe than PayPal. However, I think passing on PayPal fees would be a better option, then developers could wncourage sponsors to switch over time so they get more.
I mean, I would hope GitHub isn't using Stripe at their scale, but I could also easily see this happening (them negotiating great rates from Stripe, I mean) at their scale and, particularly, their level of prestige and since it will be used by developers.
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.
Pretty sure maintainers would be happier if GitHub announced they have to start passing on the fee instead of turning off the processor altogether. 97% of the donation vs 0%...
And if you cannot donate money, donate time. Bug reports, documentation, helping other users, pull requests (if you're a coder), even just spreading the word… If you love any given open source project, you should try to find some way to contribute to helping it improve if you're at all able.
Magit is brilliant. It makes me more effective at my job, thanks for all the hard work all the contributors have put into it over the years!
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")
> 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.
Well you've just sort of described the aforementioned tragedy of the commons again here, the trickiness is inherent and emergent in human nature, and that is _why_ it is tricky.
"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."
Btw this argument (that the TotC is a consequence of human nature) has been debunked several times (see the wikipedia article for a few). Hardin sets up a very specific scenario, and draws conclusions about human nature from it. This is a fallacy.
> 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")
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.
I didn't like it when Tarsius took over the project. I still believe that a lot of changes were unneeded. I think that some changes made it worse (and for a long time I was using my own fork from before he took over).
All this said, Magit is still the best interface to Git I know, and I would regret to see it become unmaintained.
I remember that my discontent that set off the whole thing was the interaction in magit-refs mode. It used to be the case that pressing RET on a branch would switch to that branch, while what it does today: shows the HEAD commit on that branch, which is, kind of worthless. But, I don't think this is how it worked immediately after the takeover. I think it would check out the head commit w/o switching branches putting you in a "detached head" state for no reason.
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.
Since the page doesn't explain what it is you should be donating for:
> 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.
It's not a landing page, which us why it's doing a poor job at being one. This linked URL is the donate page, but if you go up one level to the site root you will see the text you quotednin your comment. I don't see whats wrong with that, since if you enter the donate page presumably you've been on the site root first. Of course, the concept of link aggregation here kind of screws that assumption but :shrug:.
Thanks to all the new, current and former supporters!
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.
The post has rather suddenly disappeared from the front page. Don't know if that's just because it's been there for a few hours or if it's been removed for advertising.
118 comments
[ 2.9 ms ] story [ 172 ms ] threadMaybe 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.
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.
[1] https://magit.vc/manual/magit/Running-Git-Manually.html
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.
https://magit.vc/
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.
Thanks for making it for everyone!
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.
https://magit.vc/manual/magit/Status-Sections.html
https://magit.vc/manual/magit/Performance.html
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.
What is "not cool" is bumping in a thread about magit to let everybody know:
- you're an anti-political correctness warrior.
- you didn't bother to learn magit because you picked "sides" in a made up "git wars"
- you don't rtfm, but you rely on AI to give you ready-made copy-pastable commands.
This is a thread about magit. If you have nothing to say about magit, it's okay to refrain from participating.
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.
https://github.com/TimUntersberger/neogit
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.
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.
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.
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.
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.
> 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.
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.