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/
Magit, the magical Git interface (2017)
131–140 of 357 posts
Re: Magit, the magical Git interface (2017)
#132Magit 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.
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.
Re: Magit, the magical Git interface (2017)
#133Earlier quoted context omitted.
is this enough? alias magit='emacsclient -t -c -e "(progn (magit-status) (delete-other-windows))"'
could you use magit without knowing emacs? I guess you could ... but I can imagine people getting frustrated when the windows keybindings they're used to don't bring forth the expected behaviour. CUA mode exists. Would that be enough? Is magit good enough to actually force people to learn that little bit of Emacs?
I dunno, as I am an emacs user, but I have a similar binding for using calc through emacs client.
Re: Magit, the magical Git interface (2017)
#134For the sake of discussion, can we get some contrarian views? I'm using magit, along with tig, plain git and sometimes (!) even plain "vc", depending on context. I'm in the camp that thinks it's ok and it's pretty comfortable to use within emacs, but I don't see the earth shattering praise I see every time it's mentioned here. Tig for example is so much faster for history and blame perusal that I find it faster to ke…
I really like https://gitup.co.
Re: Magit, the magical Git interface (2017)
#135Magit 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…
I am the same.
After the pandemic started and I had to witness over screen share how colleagues "use" (fight) git with all sorts of GUI tools, I had to realize that no GUI can be good enough while one doesn't understand git, or, even worse, it can be contraproductive, because people using these GUIs _think_ they understand, but they don't.
I even ended up creating a (tailored) 2x90min git course...
All that said, I heard magit praised so many times, I still have some hope that it's really as good as its reputation.
(Tried fugitive, which is the vim-world's answer to magit, even learned it properly but realized I always juzt to the terminal and do stuff with the cli)
Re: Magit, the magical Git interface (2017)
#136Earlier quoted context omitted.
Next to other posters, there's also LazyGit ( https://github.com/jesseduffield/lazygit ), and vimagit ( https://github.com/jreybert/vimagit ). So yea, people are building it out of emacs!
On the lazygit repo readme an animation is shown with a single line commit prompt/dialog. Suspicious. Is there a way to expand that one-lined thing to enter more? So I looked up "multiline commit" in the issues. Several not solved but closed issues came up and multiline commit messages seem to still not be available. This would be an instant deal breaker for me, if I were trying to use lazygit. Commit messages are no…
In lazygit you can hit lowercase 'c' to bring up that one-line commit prompt, but you can also hit capital 'C' to open the commit message in your $EDITOR and write out a detailed commit message.
Re: Magit, the magical Git interface (2017)
#137Earlier 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…
I am the same. After the pandemic started and I had to witness over screen share how colleagues "use" (fight) git with all sorts of GUI tools, I had to realize that no GUI can be good enough while one doesn't understand git, or, even worse, it can be contraproductive, because people using these GUIs _think_ they understand, but they don't. I even ended up creating a (tailored) 2x90min git course... All that said, I h…
I gained a better understanding of git through this document:
https://eagain.net/articles/git-for-computer-scientists/
I'm not a computer scientist and I think it's understandable. Everything became a lot more clear in my mind once I understood the inner workings.
Re: Magit, the magical Git interface (2017)
#138Earlier quoted context omitted.
I'm pretty sure it's the main reason. Look how many times Magit shells out to git to render the status buffer, too many to count: https://github.com/magit/magit/issues/1327 In a perfect world, Emacs would link to libgit2 and Magit would be adapted and folded into the core distribution.
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.
Well, I definitely notice the difference between using magit on Windows vs magit in WSL (on the same box).
Seems like there's something going on in the windows world.
Re: Magit, the magical Git interface (2017)
#139Magit 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…
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 last example is also where you get pointed to an unsafe command for a fairly benign operation. Uncommitting is not particularly dangerous, but anything with `--hard` ought to give people a pause for thought. If you mistype it and nuke more than the last commit, that's also a bit bad - and fairly easily done.
Some other examples include shenanigans around pushing and pulling remote branches. After 10 years of using git, I still need to google it each time.
I think these commands are an accurate and reasonable representation of its inner state, but IMHO users should at least have the option of being somewhat isolated from it. Git is not a tool for algebraic manipulations on directed graphs, it is a version control software.
It has to be said, to git's credit, that although the commands are confusing to some (myself included), the tool works very well. I wanted to like mercurial more, but ended up going back to git, as much as I dislike the UI.
Re: Magit, the magical Git interface (2017)
#140For the sake of discussion, can we get some contrarian views? I'm using magit, along with tig, plain git and sometimes (!) even plain "vc", depending on context. I'm in the camp that thinks it's ok and it's pretty comfortable to use within emacs, but I don't see the earth shattering praise I see every time it's mentioned here. Tig for example is so much faster for history and blame perusal that I find it faster to ke…
I'm not familiar with tig. Is it convenient for staging chunks of code or even individual lines? Interactive rebase including re-splitting commits? Cherry-picking stuff? While working on kernel I sometimes get "looks nice, but can you reorder and re-split this 15-patches series in completely different way?" and magit is a big time-saver for that. It wasn't as useful on my previous jobs where 1k-lines commits with mes…
chunk/line staging: yes
interactive rebase: no
cherry-picking: yes