151–160 of 357 posts
I love magit, I’ve been using it for a year, which is as long as I’ve been using Emacs. But can someone please tell me how to pronounce magit? If I try to make it sound like magic, I pronounce it the same way as maggot, which seems wrong. If I put the emphasis on the second syllable so that it’s emphasizing git, that also feels weird.
Earlier quoted context omitted.
> stash some of my changes, switch branch, cherry pick a commit, switch branch, do an interactive rebase reordering commits and dropping one, pop one of my stashes > working with code becomes a fluent experience, rather than fighting with your tools I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience? I enjoy using git GUIs as well, especially for vi…
What I dislike with git terminal UI is that commands reflect the innards of git, not what the user wants to do. It also forces a deeper understanding of the innards for basic commands than ought to be necessary. Examples where undoing an operation looks totally different to doing it: - To stage a change you `add` it, to unstage you `reset HEAD` - To commit you `commit`, to undo a commit you `reset --hard HEAD^` The l…
The last example is also where you get pointed to an unsafe command”
Who pointed you there? If I want to undo my last commit, meaning the commit itself, not the changes to my file tree, shouldn’t I say `reset --soft`?
Obviously, my experience must be unique, because everyone loves Magit. It might be the most-loved piece of software ever. Every other week, there is an article on Hacker News about how it's the best piece of software ever to exist, and I've never seen anyone say anything bad about it. So I wonder what marketing techniques they use to make people feel this way; the emotions are strong, and widely shared.
Maybe there is some fundamental insecurity about Git, and Magit makes people comfortable? I've never felt that way, but I did start using Git the weekend it came out, and my Github user ID is in the low 2000s, so I might have had time to get Stockholm Syndrome with the Git UI. I suppose it's possible that the people writing these articles may not have even been born when Git came out, which is interesting to think about actually!
Earlier quoted context omitted.
> Commands are invoked, not by typing them out, but by pressing short mnemonic key sequences. It also sounds magical in the worst kind of way.
It's not magical. I forget commands all the time, then all I need to do is type `M-x` (to enter a command, like `Ctrl+P` in VSCode I think) and enter `magit ...` where I get auto-complete (if I do it often, I try to remember the keyboard shortcut, but that's optional). Also, while in magit, you can type `?` to see the list of available commands from the location where you're pointing at... the commands are single-let…
Earlier quoted context omitted.
> stash some of my changes, switch branch, cherry pick a commit, switch branch, do an interactive rebase reordering commits and dropping one, pop one of my stashes > working with code becomes a fluent experience, rather than fighting with your tools I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience? I enjoy using git GUIs as well, especially for vi…
What I dislike with git terminal UI is that commands reflect the innards of git, not what the user wants to do. It also forces a deeper understanding of the innards for basic commands than ought to be necessary. Examples where undoing an operation looks totally different to doing it: - To stage a change you `add` it, to unstage you `reset HEAD` - To commit you `commit`, to undo a commit you `reset --hard HEAD^` The l…
Glad you found something that works for you but this is definitely not true for all of us.
Magit is such an unbelievably good piece of software. If you haven't used it, please at least take a look. It seems like "just a GUI for git", but that's missing the point — many operations suddenly become frictionless, so your entire workflow changes. I regularly do things like "stash some of my changes, switch branch, cherry pick a commit, switch branch, do an interactive rebase reordering commits and dropping one,…
> stash some of my changes, switch branch, cherry pick a commit, switch branch, do an interactive rebase reordering commits and dropping one, pop one of my stashes > working with code becomes a fluent experience, rather than fighting with your tools I also do this regularly, but on my terminal. I don't feel like I'm fighting the git tools. Is this a common experience? I enjoy using git GUIs as well, especially for vi…
There is also nothing wrong with copying your entire tree to a different directory, diffing, applying patches by hand, and keeping track of what goes where.
Those are different levels of automation for the same fundamental task, but they are all legitimate solutions to the same problem, although you might end up spending more or less time to perform the same fundamental task, depending on the level of automation.
Earlier quoted context omitted.
I just called the status buffer from magit on a repo. It was 23 calls to git, mostly for rev-parse. The status buffer appeared instantaneously on a decade-old laptop. Whatever is causing the slowness you're seeing, I don't think it's just because of the number of calls. It's probably the slowness of one or two specific commands, perhaps due to repo size.
Are you testing on Windows though? I am specifically talking about Windows being the (biggest) problem with this architecture. It is very expensive to create new processes on Windows versus Unix (threads are cheaper on Windows though).
Earlier quoted context omitted.
What I dislike with git terminal UI is that commands reflect the innards of git, not what the user wants to do. It also forces a deeper understanding of the innards for basic commands than ought to be necessary. Examples where undoing an operation looks totally different to doing it: - To stage a change you `add` it, to unstage you `reset HEAD` - To commit you `commit`, to undo a commit you `reset --hard HEAD^` The l…
“ - To commit you `commit`, to undo a commit you `reset --hard HEAD^` The last example is also where you get pointed to an unsafe command” Who pointed you there? If I want to undo my last commit, meaning the commit itself, not the changes to my file tree, shouldn’t I say `reset --soft`?
But this in fact reinforces my overall point. I don't want to be messing with `reset`, hard or soft. What is `reset`? [I now know because I had to learn, but I'd really rather not].
What I want is `uncommit`, or something like that.
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/
Does anyone actually do line-by-line staging using the CLI? That sounds masochistic. Most editors/GUIs make it very easy.
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.