7 ms·

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 ma

• saghul 5y ago
  > 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.
  • feffe 5y ago
    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.
  • angio 5y ago
    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.
    • ljm 5y ago
      Not even just lines - you can selectively stage arbitrary regions too.
• the_gipsy 5y ago
  https://jonas.github.io/tig/ https://jonas.github.io/tig/
  • jaytaylor 5y ago
    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.
• masklinn 5y ago
  > 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.
  • gpderetta 5y ago
    >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.
  • yewenjie 5y ago
    I very often do line wise selection with magit, so that my commits are atomic and single-topic.
  • pronoiac 5y ago
    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.
    • masklinn 5y ago
      > 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.
      • TeMPOraL 5y ago
• skocznymroczny 5y ago
  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.
  • KronisLV 5y ago
    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.
• IshKebab 5y ago
  Does anyone actually do line-by-line staging using the CLI? That sounds masochistic. Most editors/GUIs make it very easy.
  • jawilson2 5y ago
    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.
    • IshKebab 5y ago
      Is it not easier just to review your changes? I always read through a PR after I've sent it just in case.
  • JamesSwift 5y ago
    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.
    • IshKebab 5y ago
      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?
• andrewshadura 5y ago
  Try https://github.com/andrewshadura/git-crecord https://github.com/andrewshadura/git-crecord