I love git but every time I have to use the cli instead of magit I cry a little.
When do you have to use git rather than magit?
Magit 3.0
111–120 of 144 posts
Re: Magit 3.0
#112Re: Magit 3.0
#113Earlier quoted context omitted.
When do you have to use git rather than magit?
Mostly helping others fix their mistakes on their machine.
Makes sense. I'm lucky no one asks me git questions: the few friends I have that use git know it much better than I do; most of my friends and all of my family don't use git at all.
Re: Magit 3.0
#114Looking forward to using the new release. "git at the speed of thought" describes magit quite well. Actually sometimes magit nudged me into the direction of looking up some more special git commands, to learn about them and then making use of magit's interface to them, often simply pressing one button more. Magit has not made me forget how command line git works, because it often shows me right there, what the argume…
> "git at the speed of thought" describes magit quite well.
Not under Windows, unfortunately.
Re: Magit 3.0
#115Earlier quoted context omitted.
I upvoted you but... How comes Emacs is laggy for you? I'm running a beefy Emacs setup and it is really responsive. If anything Emacs in the nineties was "Eight Megabytes And Constantly Swapping" but... We're in 2021 now and now it's still 8 MB, so it's a rounding error (I'm only exaggerating a bit). It's one my lightest app: starting Emacs, eval'ing some elisp, and exiting takes... 81 ms. Eighty-one milliseconds. To…
I was a longtime Emacs user (and vim before that) and recently a project I was working on was far too laggy for me to actually work productively on in Emacs. It was largely due to me using various LSPs within Emacs -- the frontend was in TypeScript and the backend in Go, and inevitably things would grind to a halt on a 5 year old i7 MBP with 16GB of RAM. Switched over to VSCode with as many extensions as I could find…
LSPs and Large JSX file highlighting seem slow to me.
Re: Magit 3.0
#116Earlier quoted context omitted.
I agree. I've been considering trying to replicate magit in a tui. I'm not sure if I should go for a straight port (many people might find useful, eventually) or change lots of things to make it fit my workflow (might be more likely to "finish" if I optimized for me). My dream git workflow is rebase-first, i.e. you have multiple WIP commits at any given time, and can send an unstaged hunk to any of them with the same…
Interesting! Is that workflow similar to what Quilt [1] or Stacked Git [2] is used for? And how do you achieve that now? [1] https://savannah.nongnu.org/projects/quilt [2] https://stacked-git.github.io/
Those look interesting. If I understand them right they've for mailinglist-based dev where you email patches around?
I prefer a model where you use a forge for collaboration, and don't rewrite shared history. However, you use rebase extensively locally.
Right now I use magit with fixup. It's just more keystrokes. I want to be able to highlight a change to the workdir, hit a key and select a local commit (right now it's highlight, hit the fixup shortcut, select the commit, open a rebase at the appropriate early commit, complete the rebase). I also want to be able to partially stage a newly created file (right now it's cut and paste part of it into a temp file)
I just discovered today that intellij has the concept of named changesets (i.e multiple staging areas, and you select 1+ to commit). I like it, but I don't think you can check them out and they don't work with external git commands. My temp commits would just be regular commits prefixes with "wip: "
Re: Magit 3.0
#117I wish Git would have some kind of command-server mode or libgit2 was supported with Magit to prevent needing to create new processes on Windows. Magit sometimes creates dozens of Git processes for a single operation, but because process creation is much slower on Windows than Linux, it makes Magit unusable for me on those systems. (Sadly, I don't always get a choice to just use Linux.) Simple things like magit-statu…
I also can't use magit because of this. I thought the poor
performance came mostly from my big repository with lots of
binary files but now I 'git-filter-repo'ed the .git-directory
from 2-3 GB (packed) down to 150 MB and magit is still no fun at
all (although better than before).
Re: Magit 3.0
#118Magit must be one of the best software tools ever written. I sorely missed it when I had to use IntelliJ for a few projects, so I wrote a TUI tool like Magit that can be used inside the console window of most IDEs like IntelliJ etc. Still haven't gotten around to releasing it properly, but it's easy to setup and works well enough to be a working MVP. https://github.com/hugit-project/hugit
You haven't touched its core code for two years, what happened? Gave it up?
He/she's no longer using IntelliJ.
Re: Magit 3.0
#119I wish Git would have some kind of command-server mode or libgit2 was supported with Magit to prevent needing to create new processes on Windows. Magit sometimes creates dozens of Git processes for a single operation, but because process creation is much slower on Windows than Linux, it makes Magit unusable for me on those systems. (Sadly, I don't always get a choice to just use Linux.) Simple things like magit-statu…
Magit already has some basic support for libgit. Browsing the issues I get the impression that if someone made a reasonable pull request to support libgit2 for a few dozen methods (should be easy to prioritise based on profiling) then it would be accepted. I don’t think the maintainer wants to review pull requests for one function at a time. I think one issue is perhaps that windows performance isn’t a particularly high priority and changes may not be accepted if they degrade Linux performance.
Aside: isn’t process creation more reasonable with WSL? Or can you not easily use it?
Re: Magit 3.0
#120Earlier quoted context omitted.
I'm using the Emacs Mac port on a modern(2019-era) MBP and it absolutely crawls when working on a large, multi-file Terraform code base.
Same. I have to work with large separated value files and it can get Emacs chugging on my Mac Book. Also any file large file that has any sort of highlighting (I.E a large xml file) can be difficult to work with. I'm hoping that GCC emacs will resolve some of these issues. A better Elisp backend will do so much for Emacs and all of it's modes. I think one of Guilemacs goals was to have a better elisp interpreter but…
Yea, it's quite unfortunate. Magit and Org-mode are killer, and don't really have 1:1 equivalents anywhere else.