Hacker News Reader

Comment by yewenjie | Hacker News Reader

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/

View on HN

> 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 around, and selectively unstaging is just a “d s” away.

>not hard[...] you need perfect memory and to never make any mistake

As someone without perfect memory and makes mistakes, I consider git add -p ergonomics very user unfriendly. But I guess that's your point :)

I also routinely use line-wise selection and often revert unnecessary lines when crafting the index.

I very often do line wise selection with magit, so that my commits are atomic and single-topic.

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.

Importantly, and this is why Emacs users tend to love Magit, the workflow integrates well with rest of Emacs. Your staging and diff buffers are just that - Emacs buffers. Meaning all your quality-of-life configurations and extensions are available as well.

For example, the fact that you can just jump around the buffer and stage/unstage things as you go, means you're free to use whatever you most like for that "jumping around" part. Incremental search? Sure. Ace-jump? Yes. M-x occur? If you must.

Magit on a bare-bones Emacs is extremely ergonomic on its own, but if you use and adapt Emacs for yourself, all the improvements compound on each other.

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.

https://jonas.github.io/tig/

A terminal ncurses alternative to Magit :)

    What is Tig?
    
    Tig is an ncurses-based text-mode interface for git.
    It functions mainly as a Git repository browser, but
    can also assist in staging changes for commit at
    chunk level and act as a pager for output from
    various Git commands.

Does anyone actually do line-by-line staging using the CLI? That sounds masochistic. Most editors/GUIs make it very easy.

I ALWAYS use git commit -p. I can't count the number of times clion/intellij/pycharm or vscode have done something unexpected, and I often catch things that shouldn't be committed, e.g. logging statements, commented code, etc. It takes an extra minute, but it really helps the code quality. Every senior engineer I work with (developing trading system) does the same.

Is it not easier just to review your changes? I always read through a PR after I've sent it just in case.

I always use `-p`. Its my default so its not 'more work'. Its the best way to get clean, atomic, history. It also lets me do things like mock out services or hardcode connection strings without having them accidentally exposed. I've had way too many accidental commits in the past to go back to full file add.

EDIT: also, it isnt 'line-by-line'. Its logical-chunk-by-logical-chunk. The algorithm will try to group local changes together and you need to explicitly tell it to split the chunk up if it is over eager.

I wasn't really asking how many people do line-by-line commits in general. Obviously it's useful for all the reasons you said. But it's particularly masochistic to do it via the CLI rather than through a GUI or editor.

The hunk algorithm is not very good in my experience and following the prompts to split them is just about as nice an experience as editing files with `ed`.

Have you tried using a GUI or an editor that supports staging selected lines?

Try https://github.com/andrewshadura/git-crecord

> Like how easy is it to selectively stage portions of files in the git CLI?

git add -p

Then you can decide if each hunk is staged or not.

Cool, didn't know about that. To boost Magit a bit, you can stage parts of patch hunks, I use that quite a bit.

Just select any parts of the diff using regular edit text select commands and press "s" for stage.

In my experience magit version is much faster to use since you can simply select which lines you want to stage without having to refine the hunk.

Not even just lines - you can selectively stage arbitrary regions too.

Reply on news.ycombinator.com