Live data from Hacker News

Magit, the magical Git interface (2017)

emacsair.me

101–110 of 357 posts

Re: Magit, the magical Git interface (2017)

#101
post #98

I use git from the command line, so this looked like a tool i would use. I was able to install it with apt, but i could not find any information on how to run it. Manual says "C-x g" [1], which obviously does nothing in bash. And I have no idea how to use emacs. Is there any helpful user manual? Should i give up on magit? [1] https://magit.vc/manual/magit/Getting-Started.html

Emacs comes with extensive documentation. "C-h t" opens an interactive tutorial that teaches the basics, "C-h r" opens the manual. "C-h i" opens the Texinfo browser that gives you access to even more documentation, including manuals for Emacs Lisp and Magit (if installed).

The learning curve is fairly steep in the beginning, but after ~15 years, I feel that the initial effort has paid off a lot. Not everyone likes emacs, and that's okay. But I do think it is worth giving it a try and seeing for yourself.

(As for the whole vi-vs-emacs debate, I have used both over time, and I do use vi quite regularly for quickly editing some config file. There are packages for emacs, like evil-mode, that emulate vi's key bindings and behavior, but I have not tried any of them.)

Re: Magit, the magical Git interface (2017)

#102

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 ke…

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.

Re: Magit, the magical Git interface (2017)

#103

Earlier quoted context omitted.

> Like how easy is it to selectively stage portions of files in the git CLI? It’s not hard (`git add -p`) unless you need line-wise selection. The main issue in my experience is that it’s completely linear so you need perfect memory and to never make any mistakes: git shows each hunk individually and tells you to make your choice before it shows the next, no take-backs. Magit shows the entire diff and lets you jump a…

I think 'git reset -p' lets you unstage a selection, and I'd use '/' in both searching for the chunk to unstage and to continue where I left off.

> I think 'git reset -p' lets you unstage a selection

That requires finishing the current staging, moving to unstaging, processing the unstaging (also a linear hunk-wise process), restarting the ataging, and remembering to skip the stuff you’d mistakenly staged.

The workflow of magit is much easier here, and the staging / unstaging integrates very well with reviewing the local or staged diff. Crafting good commits has way less friction and error recovery is much better.

Re: Magit, the magical Git interface (2017)

#104
post #64

Earlier quoted context omitted.

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 ca…

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 In a perfect world, Emacs would link to libgit2 and Magit would be adapted and folded into the core distribution.

[deleted]

Re: Magit, the magical Git interface (2017)

#105
post #65
post #40

This post is the epitome of "tell, don't show", when it should be the opposite. It reads like it wants to convince you to try magit, without demoing a single example of how it's superior.

> Commands are invoked, not by typing them out, but by pressing short mnemonic key sequences. It also sounds magical in the worst kind of way.

Actually, what makes Magic fantastic is that it continually shows the commands and the various action keys in the gui. This provides a very accessible way of learning a very complex tool.

Re: Magit, the magical Git interface (2017)

#106
post #69

Earlier quoted context omitted.

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…

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.

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.

Re: Magit, the magical Git interface (2017)

#107

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 ke…

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…

> 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.

Re: Magit, the magical Git interface (2017)

#108
post #69

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 ke…

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…

IntelliJ is amazing, and I'd love to have a standalone version of its git frontend for my slower machines.

Re: Magit, the magical Git interface (2017)

#109

Magit is insanely ergonomic. Like how easy is it to selectively stage portions of files in the git CLI? In magit it is usually just a few keystrokes. I wish magit-forge [0] had more features though - like I cannot create new labels from it. Please consider donating [1] to the developer if it has made your life any easier. [0] https://github.com/magit/forge [1] https://magit.vc/donate/

How many other Git GUIs have you used? Over commandline git, almost any GUI will feel like an improvement for tasks like selective staging or diffing.

I think this largely depends on the particular person and their preferences:

  - some people swear by the integration of Git into IntelliJ or other JetBrains IDEs, which is pretty good (but personally i don't really like it)
  - others enjoy a Visual Studio Code plugin or two that provides a vaguely similar and enjoyable user experience
  - personally, i rather like completely separate Git GUIs, like Git Cola (https://git-cola.github.io/), SourceTree (https://www.sourcetreeapp.com/) or GitKraken (https://www.gitkraken.com/)
  - of course, there's also a group of people who prefer more text based approaches (Vim or Emacs plugins?)
  - and there are those that enjoy using the CLI because to them it feels like the most "true" option with the least leaky abstractions
Personally, i think that you should use whatever you feel the most comfortable with and let the people around you do the same.

In my eyes, however, staging/unstaging/discarding changes to particular lines or chunks of code, as well as having visual diffs is a really useful use case for GUI solutions of any sort.

Re: Magit, the magical Git interface (2017)

#110
post #72

Tip of the day: you can have `magit` as a fast and standalone tool by using this script (require emacsclient to be setup properly): #!/usr/bin/env bash emacsclient -c --eval "(progn (magit-status) (delete-other-windows))" This will open the repository under the current path in a maximized magit window. The only downside I have for now about magit is when using `pre-commit` it can run for long sometimes, so it would b…

You should just be able to hit `$` in the magit buffer to watch the output.

Oh… when git fails I always have to navigate to the end of this buffer so I thought it would not auto-scroll. I should have tried earlier. Thanks!
Post reply on HN