10 ms·

Please help improve Magit

226 points by pmoriarty 4y ago

frantasma 4y ago
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.
- Icathian 4y ago
  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?
  - yakubin 4y ago
    Not the commenter you're replying to, but I've also struggled with Emacs freezing whenever I used Magit. See <https://news.ycombinator.com/item?id=34946051 https://news.ycombinator.com/item?id=34946051>.
- deleted 4y ago
  [deleted]
- zelphirkalt 4y ago
  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.
  - yakubin 4y ago
    Steps to reproduce: 1. Clone <https://chromium.googlesource.com/chromium/src 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.
    - zelphirkalt 4y ago
      Hm. Fails at step 1: Cloning using git on command line hangs. -- wait, correction: It now did start to clone ... lol: $ git clone https://chromium.googlesource.com/chromium/src 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.
      - yakubin 4y ago
        My issue is not that things are laggy in this case, but that they are 5 times as laggy as the command line interface. > 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.
        zelphirkalt 4y ago
        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?
- pmoriarty 4y ago
  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.
Y_Y 4y ago
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.
- BaculumMeumEst 4y ago
  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. mostly switched away from emacs as a result
  - yuuuzzzzzz 4y ago
    Enacs shouldn't freeze like that tbh, I've been using Emacs + Magit for a while now and it doesn't freeze ever.
    - School-Cotton 4y ago
      The exact described behavior has happened to me as well.
  - precompute 4y ago
    C-x 0 is the way out. That happens sometimes when focus shifts while the Transient hasn't properly exited.
    - BaculumMeumEst 4y ago
      ahhh that sounds like it would work, thanks
  - tarsius 4y ago
phkahler 4y ago
What is Magit?
- ghqst 4y ago
  The homepage of the website explains it well, as homepages should: https://magit.vc/ https://magit.vc/
- deleted 4y ago
  [deleted]
- dstala 4y ago
  Had exactly same question
- masklinn 4y ago
  It's a graphical-ish git client for emacs. 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.
  - kqr 4y ago
    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.
    - anthomtb 4y ago
      >it's not for Emacs, it's for anyone 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.
sirmac1k 4y ago
Subscribed. Big thanks to all Magit developers for creating one of the best pieces of software that I have a pleasure to use daily.
Icathian 4y ago
Appreciate the nudge! I use magit daily and it's awesome. I tossed the project some cash, I'd have paid at least that much for it. Thanks for making it for everyone!
miroljub 4y ago
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.
- kqr 4y ago
  Interesting that magit feels slower! Is it possible you're working faster in magit and that's why the commands involved feel slower?
  - spit2wind 4y ago
    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.
  - rcthompson 4y ago
    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.
    - kqr 4y ago
      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.
      - tut-urut-utut 4y ago
        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?
syntaxfree 4y ago
[flagged]
- babarock 4y ago
  It is definitely cool to support any kind of software that is useful. 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.
vasco 4y ago
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.
- rcthompson 4y ago
  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.
- switch007 4y ago
  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)
- ameminator 4y ago
  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.
  - agumonkey 4y ago
    You use a similar lib on vim ?
mi_lk 4y ago
for those who have used both Magit and neogit, how's the neogit experience as a Magit clone? https://github.com/TimUntersberger/neogit https://github.com/TimUntersberger/neogit
laserlight 4y ago
If any of us are looking for social proof, I've been regularly donating to magit. It's among the top quality software I've ever used.
- deleted 4y ago
  [deleted]
DiabloD3 4y ago
Magit was one of the coolest parts of Emacs when I spent time over in that land. I have to "settle" for tpope's Fugitive. This is one of these tiny tools that should continue to exist.
- charesjrdan 4y ago
  https://github.com/TimUntersberger/neogit https://github.com/TimUntersberger/neogit Is a port of magit to neovim. Still some stuff missing (rebase/reset iirc) but mostly does the job
  - DiabloD3 4y ago
    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.
    - pmoriarty 4y ago
      There's nothing Magit (or emacs) does that can't be done in vim, and vice-versa. 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.
      - klibertp 4y ago
        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.
clarkdale 4y ago
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] [1] https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md https://github.com/zloirock/core-js/blob/master/docs/2023-02... [2] https://en.m.wikipedia.org/wiki/Residual_(entertainment_industry) https://en.m.wikipedia.org/wiki/Residual_(entertainment_indu...
- asherah 4y ago
  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?
  - cuu508 4y ago
    This could also result in low effort PRs, similar to Hacktoberfest
  - vfclists 4y ago
    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.
- capableweb 4y ago
  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.
precompute 4y ago
Some context from a post on reddit: 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 https://magit.vc/donate - Donate to Magit! https://www.reddit.com/r/emacs/comments/11cezoq/magit_maintainer_tarsius_is_losing_donators_at/ https://www.reddit.com/r/emacs/comments/11cezoq/magit_mainta...
- photochemsyn 4y ago
  Bizarre rationalization from Github Comms: > "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.
AJRF 4y ago
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")
- zelphirkalt 4y ago
  > 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.
  - AJRF 4y ago
    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."
crabbone 4y ago
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.
- School-Cotton 4y ago
  What were some of the changes you didn’t like?
  - crabbone 4y ago
    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.
Aachen 4y ago
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.
- manx 4y ago
  I guess, the vc stands for version control here...
- kataklasm 4y ago
  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:.
tarsius 4y ago
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. See https://github.com/magit/magit/wiki/Inspired-by-Magit 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/ https://emacsair.me/2017/09/01/magit-for-non-emacs-users/ for some older musings of mine on the matter.
- omnicognate 4y ago
  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. Anyway, I couldn't live without magit. Donated.
kbradero 4y ago
he should put stripe/google pay option so people can pay on 1 click from the front page, if wikipedia does it, he can.
jkz_ 4y ago
Emacs’ main purpose to me is running Magit.

226 points by pmoriarty 4y ago

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.

Icathian 4y ago
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?
- yakubin 4y ago
  Not the commenter you're replying to, but I've also struggled with Emacs freezing whenever I used Magit. See <https://news.ycombinator.com/item?id=34946051 https://news.ycombinator.com/item?id=34946051>.
deleted 4y ago
[deleted]
zelphirkalt 4y ago
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.
- yakubin 4y ago
  Steps to reproduce: 1. Clone <https://chromium.googlesource.com/chromium/src 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.
  - zelphirkalt 4y ago
    Hm. Fails at step 1: Cloning using git on command line hangs. -- wait, correction: It now did start to clone ... lol: $ git clone https://chromium.googlesource.com/chromium/src 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.
    - yakubin 4y ago
      My issue is not that things are laggy in this case, but that they are 5 times as laggy as the command line interface. > 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.
      - zelphirkalt 4y ago
        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?
pmoriarty 4y ago
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.

Y_Y 4y ago

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.

BaculumMeumEst 4y ago
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. mostly switched away from emacs as a result
- yuuuzzzzzz 4y ago
  Enacs shouldn't freeze like that tbh, I've been using Emacs + Magit for a while now and it doesn't freeze ever.
  - School-Cotton 4y ago
    The exact described behavior has happened to me as well.
- precompute 4y ago
  C-x 0 is the way out. That happens sometimes when focus shifts while the Transient hasn't properly exited.
  - BaculumMeumEst 4y ago
    ahhh that sounds like it would work, thanks
- tarsius 4y ago

phkahler 4y ago

What is Magit?

ghqst 4y ago
The homepage of the website explains it well, as homepages should: https://magit.vc/ https://magit.vc/
deleted 4y ago
[deleted]
dstala 4y ago
Had exactly same question
masklinn 4y ago
It's a graphical-ish git client for emacs. 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.
- kqr 4y ago
  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.
  - anthomtb 4y ago
    >it's not for Emacs, it's for anyone 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.

sirmac1k 4y ago

Subscribed. Big thanks to all Magit developers for creating one of the best pieces of software that I have a pleasure to use daily.

Icathian 4y ago

Appreciate the nudge! I use magit daily and it's awesome. I tossed the project some cash, I'd have paid at least that much for it. Thanks for making it for everyone!

miroljub 4y ago

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.

kqr 4y ago
Interesting that magit feels slower! Is it possible you're working faster in magit and that's why the commands involved feel slower?
- spit2wind 4y ago
  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.
- rcthompson 4y ago
  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.
  - kqr 4y ago
    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.
    - tut-urut-utut 4y ago
      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?

syntaxfree 4y ago

[flagged]

babarock 4y ago
It is definitely cool to support any kind of software that is useful. 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.

vasco 4y ago

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.

rcthompson 4y ago
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.
switch007 4y ago
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)
ameminator 4y ago
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.
- agumonkey 4y ago
  You use a similar lib on vim ?

mi_lk 4y ago

for those who have used both Magit and neogit, how's the neogit experience as a Magit clone? https://github.com/TimUntersberger/neogit https://github.com/TimUntersberger/neogit

laserlight 4y ago

If any of us are looking for social proof, I've been regularly donating to magit. It's among the top quality software I've ever used.

deleted 4y ago
[deleted]

DiabloD3 4y ago

Magit was one of the coolest parts of Emacs when I spent time over in that land. I have to "settle" for tpope's Fugitive. This is one of these tiny tools that should continue to exist.

charesjrdan 4y ago
https://github.com/TimUntersberger/neogit https://github.com/TimUntersberger/neogit Is a port of magit to neovim. Still some stuff missing (rebase/reset iirc) but mostly does the job
- DiabloD3 4y ago
  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.
  - pmoriarty 4y ago
    There's nothing Magit (or emacs) does that can't be done in vim, and vice-versa. 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.
    - klibertp 4y ago
      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.

clarkdale 4y ago

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] [1] https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md https://github.com/zloirock/core-js/blob/master/docs/2023-02... [2] https://en.m.wikipedia.org/wiki/Residual_(entertainment_industry) https://en.m.wikipedia.org/wiki/Residual_(entertainment_indu...

asherah 4y ago
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?
- cuu508 4y ago
  This could also result in low effort PRs, similar to Hacktoberfest
- vfclists 4y ago
  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.
capableweb 4y ago
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.

precompute 4y ago

Some context from a post on reddit: 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 https://magit.vc/donate - Donate to Magit! https://www.reddit.com/r/emacs/comments/11cezoq/magit_maintainer_tarsius_is_losing_donators_at/ https://www.reddit.com/r/emacs/comments/11cezoq/magit_mainta...

photochemsyn 4y ago
Bizarre rationalization from Github Comms: > "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.

AJRF 4y ago

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

zelphirkalt 4y ago
> 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.
- AJRF 4y ago
  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."

crabbone 4y ago

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.

School-Cotton 4y ago
What were some of the changes you didn’t like?
- crabbone 4y ago
  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.

Aachen 4y ago

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.

manx 4y ago
I guess, the vc stands for version control here...
kataklasm 4y ago
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:.

tarsius 4y ago

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. See https://github.com/magit/magit/wiki/Inspired-by-Magit 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/ https://emacsair.me/2017/09/01/magit-for-non-emacs-users/ for some older musings of mine on the matter.

omnicognate 4y ago
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. Anyway, I couldn't live without magit. Donated.

kbradero 4y ago

he should put stripe/google pay option so people can pay on 1 click from the front page, if wikipedia does it, he can.

jkz_ 4y ago

Emacs’ main purpose to me is running Magit.