6 ms·

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

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...)
        iLemming 7y ago
        > nice things about magit are in vanilla git as well Magit is not trying to replace Git, it's not pretending to be something else. You still have pretty much everything what's in Git. You can still use your aliases and run vanilla git commands. So why do you need Magit? For efficiency. You don't care about your efficiency? Fine. But please don't make conclusions that the advocates of Magit don't know better. We have tried other alternatives and we have used git command line. > ability to edit the index directly, without editing the checked out files What? I don't think I understand what you're asking for here. You stage parts of a file or the whole file. It shows up in "Staged changes" section of Magit buffer. You edit the file, save it, parts that are diverse now will be shown within "Unstaged changes" in a nice diff. You may choose to stage new changes, you may resolve conflicts in a three-way-merge window, discard your changes (staged changes remain), etc. Why would you want to edit staged parts without modifying the file itself? I don't get it.
- iLemming 7y ago
  > I guess it might be really effective for those who know emacs. You don't have to know Emacs to use Magit. People often try Magit, usually because someone shows them the workflow. They don't even want to learn Emacs to begin with, but Magit looks awesome.
deleted 7y ago
[deleted]

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...)
      - iLemming 7y ago
        > nice things about magit are in vanilla git as well Magit is not trying to replace Git, it's not pretending to be something else. You still have pretty much everything what's in Git. You can still use your aliases and run vanilla git commands. So why do you need Magit? For efficiency. You don't care about your efficiency? Fine. But please don't make conclusions that the advocates of Magit don't know better. We have tried other alternatives and we have used git command line. > ability to edit the index directly, without editing the checked out files What? I don't think I understand what you're asking for here. You stage parts of a file or the whole file. It shows up in "Staged changes" section of Magit buffer. You edit the file, save it, parts that are diverse now will be shown within "Unstaged changes" in a nice diff. You may choose to stage new changes, you may resolve conflicts in a three-way-merge window, discard your changes (staged changes remain), etc. Why would you want to edit staged parts without modifying the file itself? I don't get it.
iLemming 7y ago
> I guess it might be really effective for those who know emacs. You don't have to know Emacs to use Magit. People often try Magit, usually because someone shows them the workflow. They don't even want to learn Emacs to begin with, but Magit looks awesome.

deleted 7y ago

[deleted]