I want to know if it is a hard G as in Git, or soft G as in magic. Ok, soft G might be the best choice.
It's "G" as in "GIF".
Magit, the magical Git interface (2017)
111–120 of 357 posts
Re: Magit, the magical Git interface (2017)
#112Earlier quoted context omitted.
Is the launching of processes on Windows so much slower than on Unix-type OSes that it would cause it to be "so slow" for that reason? Maybe the reason is another? Personally, I once had Magit act real slow at times because git-annex had added some git hook for something that I didn't need. Just removing that hook improved performance massively. Perhaps something similar is happening. Also, I'm not sure Emacs Lisp ca…
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.
Re: Magit, the magical Git interface (2017)
#113Earlier quoted context omitted.
Spacemacs.org brings the vi modal editing configuration to bear and is highly recommended.
If you just want that you don't need spacemacs, just evil mode.
Well, I physically cannot take the keystroke geometry if stock emacs for any stretch of time; the space bar approach is crucial for me.
Re: Magit, the magical Git interface (2017)
#114Earlier quoted context omitted.
You can, but it will be worth it for you to spend a little effort to learn the basic buffer, window, and cursor management keystrokes. My 12 year old uses magit as a git interface and nothing else in emacs. That’s not a great testimonial as it was my direction to do that, but it seems to work just fine. The areas where magit earns outsized praise is not around a basic “pull, add and commit everything, push” workflow,…
> but rather around being selective about crafting self-consistent but single-theme revisions Actually, I think git's got Magit beat on that. Magit might make it easier to stage specific lines, but git can stage specific parts of lines or even changes that are completely different than what's on the worktree, through the editing of diffs with `git add -p`'s `e` option.
What percentage of git users do this compared to the percentage of magit users staging line-by-line or confidently amending/cherry-picking/interactive-rebasing?
Re: Magit, the magical Git interface (2017)
#115If it's so great why are people not building it out of emacs :P
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 not bullet points or titles. In magit I can simply type in a new buffer as much as I want to.
Re: Magit, the magical Git interface (2017)
#116Magit 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,…
Can I like magit if I don’t like emacs?
In my experience: yes but it I have the impression it'll remain a bit of a struggle unless you go all in and learn emacs as well.
After hearing so much good of Magit in a previous thread here I thought 'ok why not?' and installed emacs and magit. That alone wasn't a walk in the park as I never used emacs before. Maybe I did something wrong but what I remember from it is mainly 'wtf x 10 and what kind of documentation is this'. After some hours I got the hang of it, and I see why it is liked, but still it didn't make me any faster with git because I already have everything needed for my main workflows (SublimeMerge + aliases). Also felt like to get any real value from it I'd need many extra hours on the learning curve and it wasn't clear to me whether the end result would actually be better than what I do now. So I skipped on it, but again: I fully understand that if you use emacs anyway it would be crazy not to use magit.
Re: Magit, the magical Git interface (2017)
#117Earlier quoted context omitted.
I use it on a low spec MacBook Air, and it works just fine for me... never noticed any kind of slowness. I only work on Emacs in small projects though... so maybe that's why it's fast for me?!
Yes it will depend on repository size.
That, and I often have multiple projects open at once. There's a note in the Magit manual about this and how it affects performance, but unfortunately, the workaround means that buffers don't get refreshed and you might see stale information unless you perform a manual refresh.
Re: Magit, the magical Git interface (2017)
#118Earlier quoted context omitted.
I use emacs and git, and never got on with magit. Not entirely sure why, but here's a braindump: - I generally dislike layers on layers; while I seriously hate the git UI, I'd rather learn that, as it's a more portable skill, than learn another UI, that relies on emacs and a package installed. First thing I do on e.g. a new cloud instance is clone a bunch of stuff, and often work on an under-setup machine for a while…
> I'd rather learn that, as it's a more portable skill, than learn another UI, that relies on emacs and a package installed FWIW, most Magit commands have 1:1 correspondence with git commands; when I'm worried I'm doing something with Magit that I wouldn't be able to replicate with CLI, I just press '$' to pop up the "process buffer", i.e. the buffer containing actual git commands being executed, along with their out…
> Switching cost is low, but typing cost is much greater.
That typing cost is why I use a GUI. While many times I can just enter `git add -u` into the terminal, there's still plenty of times where I want to be selective about what goes into the commit. If a simple glob pattern can't do it, then I'm going to reach for the GUI where I can just click on all the things I want to add to the commit in far less time than it would have taken to type all of the file names.
The GUIs also keep me immediately informed on the state of my repo. On the terminal, I'll be running `git status` a lot, just to be sure the state I think the repository in in and the actual state match up.
Re: Magit, the magical Git interface (2017)
#119Magit 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,…
Can I like magit if I don’t like emacs?
Depends on what you mean by not liking emacs. If you prefer vim, then you can just install Evil to get similar-ish modal keyboard controls. If you are more of an IDE-person who likes controlling stuff with a mouse in VS or IntelliJ, then probably no.
Re: Magit, the magical Git interface (2017)
#120For 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 message like "Implement feature X" were the norm, though.