5 ms·

How does it compare to `git add -p`?

chongli 7y ago
It's nonlinear. With `git add -p` you can press keys to go back and forth through the hunks. If there are a lot of them then it can get tedious. With Magit, on the other hand, you see everything in a window and you can use all of your usual emacs commands to scroll/search that window, and then hit the key to stage the hunks as you desire.
- kqr 7y ago
  And also trivially stage parts of hunks, not just entire hunks. It is great!
  - ReidZB 7y ago
    You can do this with `git add -p` as well, except maybe not trivially (ha). There's the 's' command to split hunks into smaller ones, and then there's also 'e' to open the patch in your editor where you can change the raw patch to whatever you'd like, although in my experience editing it correctly is not straightforward.
    - Twisol 7y ago
      I've just recently started using the `e` (edit) command in `git add -p`. It takes a little bit to get used to writing "correct" patches, but it's super powerful and I'm using it surprisingly often now.
- eitland 7y ago
  I guess it might be really effective for those who know emacs. For the rest of us we can select lines in vscode, and then either: - right click, - ctrl+shift+p <type stage, stage selected lines>
  - petepete 7y ago
    tig is also fantastic for doing this. - u for hunks - 1 for individual lines https://github.com/jonas/tig https://github.com/jonas/tig
  - gen220 7y ago
    For those of you who want to stay close to git's CLI... `git` (the binary) respects your choice of editor, as indicated by the environment variable `EDITOR`. You should be able to do something like `EDITOR=code git add -p`, it'll open up hunks for editing in `code` (or intellij, or textedit, or whatever).
    - atq2119 7y ago
      What's more, git core comes with `git gui`, which lets you stage line by line. It's not the slickest of tools, but it does the job just fine.
      - iLemming 7y ago
        But like it was noted in the comment a few levels above - Magit's workflow is nonlinear. It doesn't feel like you're switching from one activity to another. Even when rebasing (which is very transactional), you still can peek into things in other branches, stash and un-stash, resolve conflicts, etc. World doesn't have to freeze just because you're doing "git add -p".
        atq2119 7y ago
        git gui is not the same thing as git add -p. I'm sure magit is nice. It's just that everything you list as nice things about magit are in vanilla git as well. Maybe you prefer the presentation in magit, that's fine. The point is to be fully aware of the available options - which the author of the article doesn't seem to be, as they only compare against git add -p, not against git gui. The one thing that's truly missing in vanilla git as far as I know is the ability to edit the index directly, without editing the checked out files. (Does magit allow that? It's not an advertised feature in the article as far as I can see...)
- deleted 7y ago
  [deleted]
iLemming 7y ago
So let's say you stage a few different things. Then run linter/code formatter/etc. You can see the changes done by the linter, you can refine the diff (so it shows not only the lines that changed, but also highlights the details), you can expand/narrow the context (for example if you can see the change, but can't see the function header and without it it's confusing). Then you can [selectively] stage those changes. What about if you overwrite a few lines of something and now the original only exists in another branch? You can peek into that thing, check the diff, even jump into the version in the other branch (without having to check it out) and selectively "cherry-pick" lines of code. It's a seamless workflow, it doesn't feel like you're doing one thing at a time, it feels more natural and doesn't require undivided focus like: "no, I can't afford a bathroom break right now, I'm in the middle of staging, goddammit."

It's nonlinear. With `git add -p` you can press keys to go back and forth through the hunks. If there are a lot of them then it can get tedious. With Magit, on the other hand, you see everything in a window and you can use all of your usual emacs commands to scroll/search that window, and then hit the key to stage the hunks as you desire.

kqr 7y ago
And also trivially stage parts of hunks, not just entire hunks. It is great!
- ReidZB 7y ago
  You can do this with `git add -p` as well, except maybe not trivially (ha). There's the 's' command to split hunks into smaller ones, and then there's also 'e' to open the patch in your editor where you can change the raw patch to whatever you'd like, although in my experience editing it correctly is not straightforward.
  - Twisol 7y ago
    I've just recently started using the `e` (edit) command in `git add -p`. It takes a little bit to get used to writing "correct" patches, but it's super powerful and I'm using it surprisingly often now.
eitland 7y ago
I guess it might be really effective for those who know emacs. For the rest of us we can select lines in vscode, and then either: - right click, - ctrl+shift+p <type stage, stage selected lines>
- petepete 7y ago
  tig is also fantastic for doing this. - u for hunks - 1 for individual lines https://github.com/jonas/tig https://github.com/jonas/tig
- gen220 7y ago
  For those of you who want to stay close to git's CLI... `git` (the binary) respects your choice of editor, as indicated by the environment variable `EDITOR`. You should be able to do something like `EDITOR=code git add -p`, it'll open up hunks for editing in `code` (or intellij, or textedit, or whatever).
  - atq2119 7y ago
    What's more, git core comes with `git gui`, which lets you stage line by line. It's not the slickest of tools, but it does the job just fine.
    - iLemming 7y ago
      But like it was noted in the comment a few levels above - Magit's workflow is nonlinear. It doesn't feel like you're switching from one activity to another. Even when rebasing (which is very transactional), you still can peek into things in other branches, stash and un-stash, resolve conflicts, etc. World doesn't have to freeze just because you're doing "git add -p".
      - atq2119 7y ago
        git gui is not the same thing as git add -p. I'm sure magit is nice. It's just that everything you list as nice things about magit are in vanilla git as well. Maybe you prefer the presentation in magit, that's fine. The point is to be fully aware of the available options - which the author of the article doesn't seem to be, as they only compare against git add -p, not against git gui. The one thing that's truly missing in vanilla git as far as I know is the ability to edit the index directly, without editing the checked out files. (Does magit allow that? It's not an advertised feature in the article as far as I can see...)
deleted 7y ago
[deleted]

iLemming 7y ago

So let's say you stage a few different things. Then run linter/code formatter/etc. You can see the changes done by the linter, you can refine the diff (so it shows not only the lines that changed, but also highlights the details), you can expand/narrow the context (for example if you can see the change, but can't see the function header and without it it's confusing). Then you can [selectively] stage those changes. What about if you overwrite a few lines of something and now the original only exists in another branch? You can peek into that thing, check the diff, even jump into the version in the other branch (without having to check it out) and selectively "cherry-pick" lines of code. It's a seamless workflow, it doesn't feel like you're doing one thing at a time, it feels more natural and doesn't require undivided focus like: "no, I can't afford a bathroom break right now, I'm in the middle of staging, goddammit."