3 ms·

People who chose it over the default CLI, please give a few examples of why and how. I forced myself to only use magit for a week and it did not work for me, CL

People who chose it over the default CLI, please give a few examples of why and how. I forced myself to only use magit for a week and it did not work for me, CLI is still faster and more flexible. Maybe a week is not enough time, maybe I'm missing something.

roblabla 6y ago
It has saner defaults for a lot of workflows. Two small examples: stashing prompts you for a name (instead of defaulting to a useless name), and commiting will show the diff of what you're committing on the side (similar to commit -v). It also gives a rather nice in-editor workflow for adding a single hunk to the git index, which makes crafting sensible commits easier.
clktmr 6y ago
Not a Magit user, but vim-fugitive. The main reason I prefer it over the CLI is for (un)staging hunks or lines. But I still use the CLI a lot for other stuff.
OrderlyTiamat 6y ago
Are you in windows by any chance? Magit is crazy slow on windows because of it's interaction with git, which is very quick on linux. I started trying it on windows and couldn't see why people would use it, and now that I'm on linux I have no problem with it. I use both magit and git cli now. Magit is great to get an overview of the changes, the main view is very interactive which is great (e.g. chunk or even line by line staging/discarding/etc. is great) But to each their own of course.
globular-toast 6y ago
The first thing that drew me in was how easy it is to build commits. You can stage individual files, individual hunks and even individual lines really easily. Viewing diffs has a great, keyboard-driven UI. If your cursor is on a commit (for example when you're viewing logs, but it also works in most other places where you can see commits), you can press space to view the diff, and then use space and backspace to scroll up and down in the diff. Meanwhile you can still use n and p to navigate to different diffs. It's very slick. Rebasing is really fun with magit. I actually look forward to doing a nontrivial rebase.
jwr 6y ago
I would never want to go back to the original CLI. I'm constantly doing things like reverting single hunks, applying and saving stashes, looking at a stash and applying a single hunk from there, staging hunks into multiple commits — all of this is much quicker with Magit. It changed the way I use git. If all you do is simple commits, branch checkouts and cherry-picks, you might not need it. But there is so much more to Git, and Magit makes it nice and quick.
kreetx 6y ago
Magit is faster, as in pressing r i in magit's buffer does you an interactive rebase where you can choose the commit to start from. After picking that you can c(= pick)/w(= reword)/m(= edit)/k(= remove) commits from the list. Another thing that is convenient is that you can add files to index by selecting lines in a hunk. Doing that in bash is perhaps not as easy (or if it is, do say how). These are just a few examples. But in summary, magit is just a "tree of keyboard shortcuts" where you just click a few keys in sequence to get what you want. That said, I also use the cli a lot, i.e depends on if you're in emacs already, or not.
pja 6y ago
Picking hunks for resolving merge conflicts is far easier in Magit than using the CLI. Obviously you’d normally do the latter in an editor anyway, but since you’re already /in/ your editor it’s then seamless to continue the merge from within the same environment, instead of bouncing back and forth between the CLI and your editor. Rebasing in Magit is very straightforward, far easier than faffing about with the git CLI. Even more so if you’re re-ordering commits, or editing things mid-rebase. Those are just two obvious things off the top of my head. Magit is pretty great.
Derbasti 6y ago
Mostly because I don't have to tab out to a terminal, which then yanks me back into the commit message text editor anyway. Also because "c c" is faster to type than "git commit" and "s" is faster than "git add filename.foo".
robenkleene 6y ago
How do you do partial file commits with the CLI? E.g., commit one hunk in a file but not another? (Theoretically, you can do this with `git add -p`, but I’d say that’s a comparable downgrade from a GUI like Magit to using `ed` as a text editor is today.) It’s also just silly to view a multi-file diff, which is hierarchal (File > Changes) just as a flat terminal dump. It's fine for quick diffs that follow a simple pattern, but I wouldn't want to review a complex diff that way.

roblabla 6y ago

It has saner defaults for a lot of workflows. Two small examples: stashing prompts you for a name (instead of defaulting to a useless name), and commiting will show the diff of what you're committing on the side (similar to commit -v). It also gives a rather nice in-editor workflow for adding a single hunk to the git index, which makes crafting sensible commits easier.

clktmr 6y ago

Not a Magit user, but vim-fugitive. The main reason I prefer it over the CLI is for (un)staging hunks or lines. But I still use the CLI a lot for other stuff.

OrderlyTiamat 6y ago

Are you in windows by any chance? Magit is crazy slow on windows because of it's interaction with git, which is very quick on linux. I started trying it on windows and couldn't see why people would use it, and now that I'm on linux I have no problem with it. I use both magit and git cli now. Magit is great to get an overview of the changes, the main view is very interactive which is great (e.g. chunk or even line by line staging/discarding/etc. is great) But to each their own of course.

globular-toast 6y ago

The first thing that drew me in was how easy it is to build commits. You can stage individual files, individual hunks and even individual lines really easily. Viewing diffs has a great, keyboard-driven UI. If your cursor is on a commit (for example when you're viewing logs, but it also works in most other places where you can see commits), you can press space to view the diff, and then use space and backspace to scroll up and down in the diff. Meanwhile you can still use n and p to navigate to different diffs. It's very slick. Rebasing is really fun with magit. I actually look forward to doing a nontrivial rebase.

jwr 6y ago

I would never want to go back to the original CLI. I'm constantly doing things like reverting single hunks, applying and saving stashes, looking at a stash and applying a single hunk from there, staging hunks into multiple commits — all of this is much quicker with Magit. It changed the way I use git. If all you do is simple commits, branch checkouts and cherry-picks, you might not need it. But there is so much more to Git, and Magit makes it nice and quick.

kreetx 6y ago

Magit is faster, as in pressing r i in magit's buffer does you an interactive rebase where you can choose the commit to start from. After picking that you can c(= pick)/w(= reword)/m(= edit)/k(= remove) commits from the list. Another thing that is convenient is that you can add files to index by selecting lines in a hunk. Doing that in bash is perhaps not as easy (or if it is, do say how). These are just a few examples. But in summary, magit is just a "tree of keyboard shortcuts" where you just click a few keys in sequence to get what you want. That said, I also use the cli a lot, i.e depends on if you're in emacs already, or not.

pja 6y ago

Picking hunks for resolving merge conflicts is far easier in Magit than using the CLI. Obviously you’d normally do the latter in an editor anyway, but since you’re already /in/ your editor it’s then seamless to continue the merge from within the same environment, instead of bouncing back and forth between the CLI and your editor. Rebasing in Magit is very straightforward, far easier than faffing about with the git CLI. Even more so if you’re re-ordering commits, or editing things mid-rebase. Those are just two obvious things off the top of my head. Magit is pretty great.

Derbasti 6y ago

Mostly because I don't have to tab out to a terminal, which then yanks me back into the commit message text editor anyway. Also because "c c" is faster to type than "git commit" and "s" is faster than "git add filename.foo".

robenkleene 6y ago

How do you do partial file commits with the CLI? E.g., commit one hunk in a file but not another? (Theoretically, you can do this with `git add -p`, but I’d say that’s a comparable downgrade from a GUI like Magit to using `ed` as a text editor is today.) It’s also just silly to view a multi-file diff, which is hierarchal (File > Changes) just as a flat terminal dump. It's fine for quick diffs that follow a simple pattern, but I wouldn't want to review a complex diff that way.