8 ms·

For the sake of discussion, can we get some contrarian views? I'm using magit, along with tig, plain git and sometimes (!) even plain "vc", depending on contex

For the sake of discussion, can we get some contrarian views? I'm using magit, along with tig, plain git and sometimes (!) even plain "vc", depending on context. I'm in the camp that thinks it's ok and it's pretty comfortable to use within emacs, but I don't see the earth shattering praise I see every time it's mentioned here. Tig for example is so much faster for history and blame perusal that I find it faster to keep it open in another terminal and just switch to it. Altenatives? Contrarians?

jidiculous 5y ago
I can't imagine (haven't tried it so I'm just speculating here) that Magit functions very comfortably on something like a deep clone of the Linux repo, but I think there would be very few monolithic projects most of us would encounter with that kind of lengthy history in our day-to-day work. Maybe some Googlers could weigh in on how their large repos are handled by Magit?
grumpyprole 5y ago
Magit is unfortunately so slow on Windows that it's unusable. This is a real shame, because the UI is fantastic. I think a better architecture would use libgit2 calls rather than launching multiple git processes for every single magit operation.
- jolmg 5y ago
  Is the launching of processes on Windows so much slower than on Unix-type OSes that it would cause it to be "so slow" for that reason? Maybe the reason is another? Personally, I once had Magit act real slow at times because git-annex had added some git hook for something that I didn't need. Just removing that hook improved performance massively. Perhaps something similar is happening. Also, I'm not sure Emacs Lisp can interface directly with C libraries, so using libgit2 might not be an option.
  - grumpyprole 5y ago
    I'm pretty sure it's the main reason. Look how many times Magit shells out to git to render the status buffer, too many to count: https://github.com/magit/magit/issues/1327 https://github.com/magit/magit/issues/1327 In a perfect world, Emacs would link to libgit2 and Magit would be adapted and folded into the core distribution.
    - deleted 5y ago
      [deleted]
    - jolmg 5y ago
      I just called the status buffer from magit on a repo. It was 23 calls to git, mostly for rev-parse. The status buffer appeared instantaneously on a decade-old laptop. Whatever is causing the slowness you're seeing, I don't think it's just because of the number of calls. It's probably the slowness of one or two specific commands, perhaps due to repo size.
      - disgruntledphd2 5y ago
        Well, I definitely notice the difference between using magit on Windows vs magit in WSL (on the same box). Seems like there's something going on in the windows world.
      - grumpyprole 5y ago
        Are you testing on Windows though? I am specifically talking about Windows being the (biggest) problem with this architecture. It is very expensive to create new processes on Windows versus Unix (threads are cheaper on Windows though).
        jolmg 5y ago
        Another commenter said that they also experienced slowdowns on macOS, so I thought the OS actually didn't matter much on this, but based on disgruntledphd2's comment, I guess it does.
      - foobarbaz33 5y ago
  - dhess 5y ago
    Unfortunately, it's pretty slow on macOS, as well. I love Magit, but there are times when I feel like it's hindering me more than helping due to the performance.
    - brabel 5y ago
      I use it on a low spec MacBook Air, and it works just fine for me... never noticed any kind of slowness. I only work on Emacs in small projects though... so maybe that's why it's fast for me?!
      - grumpyprole 5y ago
        Yes it will depend on repository size.
        dhess 5y ago
        That, and I often have multiple projects open at once. There's a note in the Magit manual about this and how it affects performance, but unfortunately, the workaround means that buffers don't get refreshed and you might see stale information unless you perform a manual refresh.
    - rgrmrts 5y ago
      I noticed better performance using native-comp in magit (and the rest of emacs for what it’s worth) on macOS. Might be worth a shot!
  - gpderetta 5y ago
    > Also, I'm not sure Emacs Lisp can interface directly with C libraries, so using libgit2 might not be an option. I believe these days (i.e. since emacs 25) it can via dynamic modules. There are ffi libraries built on top of it.
- bsdubernerd 5y ago
  Magit is not particularly fast on *nix either. Most of the UI operates on buffers which are prepared infrequently, so the latency doesn't have significant impact. This is a very good UI design for magit itself, since staying within emacs provides bigger benefits in most cases. However, my own cited example about browsing history and blames is one case where I cannot just stomach the subpar efficiency. Tig also runs git as a subprocess, but every view is truly incremental and you can scroll through any buffer in any view and there's absolutely zero delay. Night and day even when comparing emacs with JIT. Like for magit, tig has one keystroke shortcuts that make sense (which IMHO is pretty common on good TUI programs) and can perform many git operations directly from the spot you're looking at. I also consider the visual space usage in tig to be much more efficient as well. Especially the blame view, which I find still wasteful in all modes compared to tig's. I frequently use a customized vc-annotate instead. Magit hooks also considerably slow down operations on remote files, which can be quite annoying if you don't actively need to use git while editing. Don't get me wrong - I like magit. But like org-mode, I don't get the glorification it gets.
rich_sasha 5y ago
I use emacs and git, and never got on with magit. Not entirely sure why, but here's a braindump: - I generally dislike layers on layers; while I seriously hate the git UI, I'd rather learn that, as it's a more portable skill, than learn another UI, that relies on emacs and a package installed. First thing I do on e.g. a new cloud instance is clone a bunch of stuff, and often work on an under-setup machine for a while. For similar reasons, I don't use shells like Fish, which, nice as they may be, funnel me into something totally incompatible with good old sh. Bash and zsh, as far as I use them, are compatible. - I work in tmux, and emacs in terminal, the overhead of switching to a terminal and typing some git stuff is tiny. - I tried magit and just didn't get it. I couldn't couldn't find a happy path where I thought, "ah yes this is niice".
- jolmg 5y ago
  > - I tried magit and just didn't get it. I couldn't couldn't find a happy path where I thought, "ah yes this is niice". I mostly use plain git instead of Magit, for more or less the same reason, although I like git's UI. I did find a happy path, though. Magit's blame interface is very nice to recursively call git-blame and navigate history of pieces of code. I ended up making a CLI program to improve git blame[1] so that I didn't end up switching to Magit just for that, but doing git-blame from Magit is still better. [1] https://github.com/jolmg/git-reblame https://github.com/jolmg/git-reblame
- yodsanklai 5y ago
  I'm not a terminal maximalist, but most git actions are easy to perform from the terminal. Switching to a terminal and typing the right git command has little overhead, and it's a universal way of doing things.
- laserlight 5y ago
  > I generally dislike layers on layers; while I seriously hate the git UI, I'd rather learn that I'm surprised to hear this. Magit is a very thin layer on top of git. Not thin in the technical sense, but in UI/UX sense. Keybindings map almost one to one with git CLI. Arguments to the git CLI are explicitly stated. Executed git command is reported. I learned git better by using Magit.
brabel 5y ago
Ok, let me try. I prefer IntelliJ's git interface. Magit can do everything IJ can, but in IJ, I can find how to do things more easily and it just feels easier to do things, probably because it's much more GUI than text compared to Magit. For example, difficult merges are extremely easy in IntelliJ, I can edit code in the diff view itself while I resolve conflicts... in Magit it requires getting used to the different diff views, something I am still trying to figure out, but it seems trickier to do "in-place" changes in the code. That said: I probably only prefer IJ because I've been using it much longer than I have used Magit... and the difference for me is very small, so I suspect the more I use Magit, the more the gap will close and I may eventually like it even more than IJ.
- seastonATccs 5y ago
  IntelliJ GIT ui/ux is so completely frictionless it's magical at times. The only downside is that it makes incredibly complex operations trivial that I never learned git from the cli beyond the very basics.
  - ziml77 5y ago
    Really? I tried it yesterday from within Rider and I gave up on it because I couldn't even figure out how to push or pull. Best I could find was fetch. Not the biggest deal since neither of those commands require interacting with the output which makes them equally easy to run from the terminal, but it's strange that they're not available in an immediately obvious place.
    - lima 5y ago
      Ctrl-T for pull, Ctrl-Shift-K for push.
    - shagie 5y ago
      You can customize the menu (and I do) to add a Git menu sub panel (for lack of a better word) that has an up and down arrow for push and pull. In the lower right, there's the vcs "where you're at" that shows the current branch. From there you can see the status of your branch compared to others (if you need to fetch them), or you can update branches (even those you're not currently on) along with branch specific operations including push. You can access the same in the git panel with right clicking on branches in the log. At any time, you can double tap shift to bring up the "search everything" window. Within that, if you type "git push", it will display that action along with the menu that action is in and any key shortcuts that are bound to it.
AJRF 5y ago
I get the same impression using org mode vs hearing people talk about it. It's great! but the way it's talked about makes you think it will change your life and finally stop you being a lazy procrastinating fool. It's very cool and flexible and doesn't tie you in to any big tech provider (yay!), but it's just an outliner at the end of the day.
- TheFreim 5y ago
  I like org mode, I use it every single day, and I'd agree most of the time. 9/10 I'm using it as a glorified markdown editor, but on that 1/10 occasion where I get to do something really cool is where it feels magical.
ChrisMarshallNY 5y ago
I'm not going to post anything "contrarian," so to speak, because this really does seem to be an excellent tool. I will say that I won't be using it, as I use GUI tools, with a far smaller "power" level, and use command-line Git for the few times I need anything fancy.
caskstrength 5y ago
I'm not familiar with tig. Is it convenient for staging chunks of code or even individual lines? Interactive rebase including re-splitting commits? Cherry-picking stuff? While working on kernel I sometimes get "looks nice, but can you reorder and re-split this 15-patches series in completely different way?" and magit is a big time-saver for that. It wasn't as useful on my previous jobs where 1k-lines commits with message like "Implement feature X" were the norm, though.
- VMG 5y ago
  chunk/line staging: yes interactive rebase: no cherry-picking: yes
incanus77 5y ago
I really like https://gitup.co https://gitup.co.
jimbobimbo 5y ago
I'm using Visual Studio Code for basic git functionality and switch to Visual Studio proper when I have to deal with gnarly merges. Merge UX is fantastic in VS.
eddieh 5y ago
My contrarian view: I pronounce it maggot. I think Mag-it sounds weird. That said, I’ve financially backed Magits development (Kickstarter iirc) and I use it almost everyday, but I don’t do merges with it. I’ve had some large merges go really slow thru Magit. So I always do my merges in the terminal using the plain git CLI.
bentcorner 5y ago
I picked up Sublime Text + Merge a few months ago (I wanted Sublime Text and figured I'd try out Merge since the bundle was cheaper), and it turns out I use Sublime Merge way more. (Sublime Text is fine but for my workflow it has a bunch of gaps with Visual Studio that I haven't been able to fill). Sublime Merge and vscode + git plugins are pretty close to each other but Sublime Merge does everything I need with less fuss. vscode just has some rough edges due to it's swiss-army knife approach that Sublime Merge doesn't.

jidiculous 5y ago

I can't imagine (haven't tried it so I'm just speculating here) that Magit functions very comfortably on something like a deep clone of the Linux repo, but I think there would be very few monolithic projects most of us would encounter with that kind of lengthy history in our day-to-day work. Maybe some Googlers could weigh in on how their large repos are handled by Magit?

grumpyprole 5y ago

Magit is unfortunately so slow on Windows that it's unusable. This is a real shame, because the UI is fantastic. I think a better architecture would use libgit2 calls rather than launching multiple git processes for every single magit operation.

jolmg 5y ago
Is the launching of processes on Windows so much slower than on Unix-type OSes that it would cause it to be "so slow" for that reason? Maybe the reason is another? Personally, I once had Magit act real slow at times because git-annex had added some git hook for something that I didn't need. Just removing that hook improved performance massively. Perhaps something similar is happening. Also, I'm not sure Emacs Lisp can interface directly with C libraries, so using libgit2 might not be an option.
- grumpyprole 5y ago
  I'm pretty sure it's the main reason. Look how many times Magit shells out to git to render the status buffer, too many to count: https://github.com/magit/magit/issues/1327 https://github.com/magit/magit/issues/1327 In a perfect world, Emacs would link to libgit2 and Magit would be adapted and folded into the core distribution.
  - deleted 5y ago
    [deleted]
  - jolmg 5y ago
    I just called the status buffer from magit on a repo. It was 23 calls to git, mostly for rev-parse. The status buffer appeared instantaneously on a decade-old laptop. Whatever is causing the slowness you're seeing, I don't think it's just because of the number of calls. It's probably the slowness of one or two specific commands, perhaps due to repo size.
    - disgruntledphd2 5y ago
      Well, I definitely notice the difference between using magit on Windows vs magit in WSL (on the same box). Seems like there's something going on in the windows world.
    - grumpyprole 5y ago
      Are you testing on Windows though? I am specifically talking about Windows being the (biggest) problem with this architecture. It is very expensive to create new processes on Windows versus Unix (threads are cheaper on Windows though).
      - jolmg 5y ago
        Another commenter said that they also experienced slowdowns on macOS, so I thought the OS actually didn't matter much on this, but based on disgruntledphd2's comment, I guess it does.
    - foobarbaz33 5y ago
- dhess 5y ago
  Unfortunately, it's pretty slow on macOS, as well. I love Magit, but there are times when I feel like it's hindering me more than helping due to the performance.
  - brabel 5y ago
    I use it on a low spec MacBook Air, and it works just fine for me... never noticed any kind of slowness. I only work on Emacs in small projects though... so maybe that's why it's fast for me?!
    - grumpyprole 5y ago
      Yes it will depend on repository size.
      - dhess 5y ago
        That, and I often have multiple projects open at once. There's a note in the Magit manual about this and how it affects performance, but unfortunately, the workaround means that buffers don't get refreshed and you might see stale information unless you perform a manual refresh.
  - rgrmrts 5y ago
    I noticed better performance using native-comp in magit (and the rest of emacs for what it’s worth) on macOS. Might be worth a shot!
- gpderetta 5y ago
  > Also, I'm not sure Emacs Lisp can interface directly with C libraries, so using libgit2 might not be an option. I believe these days (i.e. since emacs 25) it can via dynamic modules. There are ffi libraries built on top of it.
bsdubernerd 5y ago
Magit is not particularly fast on *nix either. Most of the UI operates on buffers which are prepared infrequently, so the latency doesn't have significant impact. This is a very good UI design for magit itself, since staying within emacs provides bigger benefits in most cases. However, my own cited example about browsing history and blames is one case where I cannot just stomach the subpar efficiency. Tig also runs git as a subprocess, but every view is truly incremental and you can scroll through any buffer in any view and there's absolutely zero delay. Night and day even when comparing emacs with JIT. Like for magit, tig has one keystroke shortcuts that make sense (which IMHO is pretty common on good TUI programs) and can perform many git operations directly from the spot you're looking at. I also consider the visual space usage in tig to be much more efficient as well. Especially the blame view, which I find still wasteful in all modes compared to tig's. I frequently use a customized vc-annotate instead. Magit hooks also considerably slow down operations on remote files, which can be quite annoying if you don't actively need to use git while editing. Don't get me wrong - I like magit. But like org-mode, I don't get the glorification it gets.

rich_sasha 5y ago

I use emacs and git, and never got on with magit. Not entirely sure why, but here's a braindump: - I generally dislike layers on layers; while I seriously hate the git UI, I'd rather learn that, as it's a more portable skill, than learn another UI, that relies on emacs and a package installed. First thing I do on e.g. a new cloud instance is clone a bunch of stuff, and often work on an under-setup machine for a while. For similar reasons, I don't use shells like Fish, which, nice as they may be, funnel me into something totally incompatible with good old sh. Bash and zsh, as far as I use them, are compatible. - I work in tmux, and emacs in terminal, the overhead of switching to a terminal and typing some git stuff is tiny. - I tried magit and just didn't get it. I couldn't couldn't find a happy path where I thought, "ah yes this is niice".

jolmg 5y ago
> - I tried magit and just didn't get it. I couldn't couldn't find a happy path where I thought, "ah yes this is niice". I mostly use plain git instead of Magit, for more or less the same reason, although I like git's UI. I did find a happy path, though. Magit's blame interface is very nice to recursively call git-blame and navigate history of pieces of code. I ended up making a CLI program to improve git blame[1] so that I didn't end up switching to Magit just for that, but doing git-blame from Magit is still better. [1] https://github.com/jolmg/git-reblame https://github.com/jolmg/git-reblame
yodsanklai 5y ago
I'm not a terminal maximalist, but most git actions are easy to perform from the terminal. Switching to a terminal and typing the right git command has little overhead, and it's a universal way of doing things.
laserlight 5y ago
> I generally dislike layers on layers; while I seriously hate the git UI, I'd rather learn that I'm surprised to hear this. Magit is a very thin layer on top of git. Not thin in the technical sense, but in UI/UX sense. Keybindings map almost one to one with git CLI. Arguments to the git CLI are explicitly stated. Executed git command is reported. I learned git better by using Magit.

brabel 5y ago

Ok, let me try. I prefer IntelliJ's git interface. Magit can do everything IJ can, but in IJ, I can find how to do things more easily and it just feels easier to do things, probably because it's much more GUI than text compared to Magit. For example, difficult merges are extremely easy in IntelliJ, I can edit code in the diff view itself while I resolve conflicts... in Magit it requires getting used to the different diff views, something I am still trying to figure out, but it seems trickier to do "in-place" changes in the code. That said: I probably only prefer IJ because I've been using it much longer than I have used Magit... and the difference for me is very small, so I suspect the more I use Magit, the more the gap will close and I may eventually like it even more than IJ.

seastonATccs 5y ago
IntelliJ GIT ui/ux is so completely frictionless it's magical at times. The only downside is that it makes incredibly complex operations trivial that I never learned git from the cli beyond the very basics.
- ziml77 5y ago
  Really? I tried it yesterday from within Rider and I gave up on it because I couldn't even figure out how to push or pull. Best I could find was fetch. Not the biggest deal since neither of those commands require interacting with the output which makes them equally easy to run from the terminal, but it's strange that they're not available in an immediately obvious place.
  - lima 5y ago
    Ctrl-T for pull, Ctrl-Shift-K for push.
  - shagie 5y ago
    You can customize the menu (and I do) to add a Git menu sub panel (for lack of a better word) that has an up and down arrow for push and pull. In the lower right, there's the vcs "where you're at" that shows the current branch. From there you can see the status of your branch compared to others (if you need to fetch them), or you can update branches (even those you're not currently on) along with branch specific operations including push. You can access the same in the git panel with right clicking on branches in the log. At any time, you can double tap shift to bring up the "search everything" window. Within that, if you type "git push", it will display that action along with the menu that action is in and any key shortcuts that are bound to it.

AJRF 5y ago

I get the same impression using org mode vs hearing people talk about it. It's great! but the way it's talked about makes you think it will change your life and finally stop you being a lazy procrastinating fool. It's very cool and flexible and doesn't tie you in to any big tech provider (yay!), but it's just an outliner at the end of the day.

TheFreim 5y ago
I like org mode, I use it every single day, and I'd agree most of the time. 9/10 I'm using it as a glorified markdown editor, but on that 1/10 occasion where I get to do something really cool is where it feels magical.

ChrisMarshallNY 5y ago

I'm not going to post anything "contrarian," so to speak, because this really does seem to be an excellent tool. I will say that I won't be using it, as I use GUI tools, with a far smaller "power" level, and use command-line Git for the few times I need anything fancy.

caskstrength 5y ago

I'm not familiar with tig. Is it convenient for staging chunks of code or even individual lines? Interactive rebase including re-splitting commits? Cherry-picking stuff? While working on kernel I sometimes get "looks nice, but can you reorder and re-split this 15-patches series in completely different way?" and magit is a big time-saver for that. It wasn't as useful on my previous jobs where 1k-lines commits with message like "Implement feature X" were the norm, though.

VMG 5y ago
chunk/line staging: yes interactive rebase: no cherry-picking: yes

incanus77 5y ago

I really like https://gitup.co https://gitup.co.

jimbobimbo 5y ago

I'm using Visual Studio Code for basic git functionality and switch to Visual Studio proper when I have to deal with gnarly merges. Merge UX is fantastic in VS.

eddieh 5y ago

My contrarian view: I pronounce it maggot. I think Mag-it sounds weird. That said, I’ve financially backed Magits development (Kickstarter iirc) and I use it almost everyday, but I don’t do merges with it. I’ve had some large merges go really slow thru Magit. So I always do my merges in the terminal using the plain git CLI.

bentcorner 5y ago

I picked up Sublime Text + Merge a few months ago (I wanted Sublime Text and figured I'd try out Merge since the bundle was cheaper), and it turns out I use Sublime Merge way more. (Sublime Text is fine but for my workflow it has a bunch of gaps with Visual Studio that I haven't been able to fill). Sublime Merge and vscode + git plugins are pretty close to each other but Sublime Merge does everything I need with less fuss. vscode just has some rough edges due to it's swiss-army knife approach that Sublime Merge doesn't.