4 ms·

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

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.
TeMPOraL 5y ago
> I'd rather learn that, as it's a more portable skill, than learn another UI, that relies on emacs and a package installed FWIW, most Magit commands have 1:1 correspondence with git commands; when I'm worried I'm doing something with Magit that I wouldn't be able to replicate with CLI, I just press '$' to pop up the "process buffer", i.e. the buffer containing actual git commands being executed, along with their output. Conversely, I still read git documentation to figure out more advanced Magit workflows. My way of looking at it is, Magit is just an ergonomics layer on top of git - it doesn't introduce new abstractions, it just lets you do stuff in a more efficient and interactive way. The love comes from that efficiency - the improvement is big enough to make a qualitative difference and affect the way I interact with git. (And, of course, you can just press !! and type in whatever git CLI command you want, to run in context of your repository.) > the overhead of switching to a terminal and typing some git stuff is tiny. Switching cost is low, but typing cost is much greater. Of course, everyone has their own preferences. I personally swear by Magit, and I'd love to have more command line tools be integrated with equivalent interface. Magit's UX paradigm isn't a total replacement for all CLI - but it's perfect for tools you repetitively invoke with different parameters to sculpt something.
- ziml77 5y ago
  > Switching cost is low, but typing cost is much greater. That typing cost is why I use a GUI. While many times I can just enter `git add -u` into the terminal, there's still plenty of times where I want to be selective about what goes into the commit. If a simple glob pattern can't do it, then I'm going to reach for the GUI where I can just click on all the things I want to add to the commit in far less time than it would have taken to type all of the file names. The GUIs also keep me immediately informed on the state of my repo. On the terminal, I'll be running `git status` a lot, just to be sure the state I think the repository in in and the actual state match up.
  - TeMPOraL 5y ago
    Yup. But then, clicking time (or rather, navigating your mouse) is also slow. Where Magit shines is in being a GUI (a TUI), so you're always informed on the state of the repo, but it's also fully keyboard operated, so you don't have to click on things. The popup-based paradigm for keyboard operation helps with discoverability - first few times around, you'll be going slow to learn what key does what, but after that, you'll be issuing most commands from memory.

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.

TeMPOraL 5y ago

> I'd rather learn that, as it's a more portable skill, than learn another UI, that relies on emacs and a package installed FWIW, most Magit commands have 1:1 correspondence with git commands; when I'm worried I'm doing something with Magit that I wouldn't be able to replicate with CLI, I just press '$' to pop up the "process buffer", i.e. the buffer containing actual git commands being executed, along with their output. Conversely, I still read git documentation to figure out more advanced Magit workflows. My way of looking at it is, Magit is just an ergonomics layer on top of git - it doesn't introduce new abstractions, it just lets you do stuff in a more efficient and interactive way. The love comes from that efficiency - the improvement is big enough to make a qualitative difference and affect the way I interact with git. (And, of course, you can just press !! and type in whatever git CLI command you want, to run in context of your repository.) > the overhead of switching to a terminal and typing some git stuff is tiny. Switching cost is low, but typing cost is much greater. Of course, everyone has their own preferences. I personally swear by Magit, and I'd love to have more command line tools be integrated with equivalent interface. Magit's UX paradigm isn't a total replacement for all CLI - but it's perfect for tools you repetitively invoke with different parameters to sculpt something.

ziml77 5y ago
> Switching cost is low, but typing cost is much greater. That typing cost is why I use a GUI. While many times I can just enter `git add -u` into the terminal, there's still plenty of times where I want to be selective about what goes into the commit. If a simple glob pattern can't do it, then I'm going to reach for the GUI where I can just click on all the things I want to add to the commit in far less time than it would have taken to type all of the file names. The GUIs also keep me immediately informed on the state of my repo. On the terminal, I'll be running `git status` a lot, just to be sure the state I think the repository in in and the actual state match up.
- TeMPOraL 5y ago
  Yup. But then, clicking time (or rather, navigating your mouse) is also slow. Where Magit shines is in being a GUI (a TUI), so you're always informed on the state of the repo, but it's also fully keyboard operated, so you don't have to click on things. The popup-based paradigm for keyboard operation helps with discoverability - first few times around, you'll be going slow to learn what key does what, but after that, you'll be issuing most commands from memory.