Magit 3.0(emacsair.me) |
Not under Windows, unfortunately.
I'll give it a try
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.
emacs -Q -nw --load magit-init.el --eval '(progn (magit-status) (delete-other-windows)'
[1] https://www.wisdomandwonder.com/article/10787/emacsorg-mode-...
https://magit.vc/manual/magit/Microsoft-Windows-Performance....
Aside: isn’t process creation more reasonable with WSL? Or can you not easily use it?
In my experience WSL is overall much slower than cygwin.
But Magit is so good that I start emacs up just to use it as my Git interface if I can't get by just with the CLI.
Sadly there is no Vim plugin that is competitive. There is vimagit [1], but it's not on par.
Nice to see Forge getting some attention. One less reason to ever leave Emacs is always welcome.
It’s great that parts of the magit experience have been separated into packages. Perhaps now mercurial, perforce etc can get clients similar to magit in quality.
alias magit='emacs -nw --eval "(magit-status)"'To address GP comment, you can just install vanilla emacs, then install magit, and just use that as your "standalone" app.
Magit – A Git Porcelain inside Emacs - https://news.ycombinator.com/item?id=24431216 - Sept 2020 (83 comments)
A walk through the Magit interface - https://news.ycombinator.com/item?id=21729597 - Dec 2019 (81 comments)
Magit 2.13 released - https://news.ycombinator.com/item?id=17220630 - June 2018 (49 comments)
Show HN: Magit, the magical Git interface - https://news.ycombinator.com/item?id=15358723 - Sept 2017 (5 comments)
Magit Kickstarter fully funded - https://news.ycombinator.com/item?id=15312288 - Sept 2017 (71 comments)
Emacs and Magit - https://news.ycombinator.com/item?id=14819256 - July 2017 (174 comments)
Magit: a Git porcelain inside emacs - https://news.ycombinator.com/item?id=10643977 - Nov 2015 (14 comments)
What's new in Magit 2.x - https://news.ycombinator.com/item?id=9936095 - July 2015 (23 comments)
Using Emacs and Git with Magit 2.1 - https://news.ycombinator.com/item?id=9873237 - July 2015 (29 comments)
Meet Magit - Git Mode for Emacs - https://news.ycombinator.com/item?id=2543265 - May 2011 (4 comments)
I am a non Emac user and wonder why no one tries to bring something similar client for non Emac population.
Here's a previous discussion: https://news.ycombinator.com/item?id=10090348
p.s. Somebody correct me if I'm wrong.
There have been several times that I tried something with magit, and messed things up enough that I just dropped into a shell and did everything with the git command line
Have a look:
Sourcetree is mouse-oriented, and to me it has the same disadvantages as all git GUI clients: I'm never quite sure what it's doing behind the scenes, and it cannot quite do everything useful that command line git can do.
Magit is keyboard-centric like emacs. Yes, so is the command line but Magit relies on individual keystrokes rather than typing in a line of commands and hitting <return>. The result is that once you get used to Magit you can fly through git operations and it's almost always quite clear what git operations Magit is doing. There are still a few exotic command line git operations Magit won't do but I almost never need them.
SourceTree is terrible IMO. I've had to help so many coworkers (who don't want to learn proper terminal git) unfuck their local repos after SourceTree did god knows what to it. Other git GUIs like Fork or Git Tower never caused these same issues in my experience. If you are currently using SourceTree I would recommend trying this instead: https://git-fork.com/
This Magit update is not renaming branches or telling you what branch name to use. Quite the opposite. It's a switch from assuming everyone uses only one of the many conventions out there, to having out-of-the-box support for all the major ones.
It went right in the trash and I haven't looked back. Do. Not. Break. Workflows. Ever. If a user knows they're supposed to open a file in a specific format in their editor, and you inject your pixie dust into the guts of their editor thinking you know better what they want to do than they do, then all you've done is prove to the user that you cannot be trusted to support their work.
Seriously: I don't use magit and don't want to learn its new tooling because I don't trust it not to break itself.
It's one my lightest app: starting Emacs, eval'ing some elisp, and exiting takes... 81 ms. Eighty-one milliseconds. To start an entire Emacs instance from scratch (no "daemon" trickery: a real full Emacs instance), eval'ing "kill emacs" (ok, a small program if any bu still) and exiting.
I don't know which editor, in this day and age, can start and exit in 81 ms (besides vim and nano)?
Launching my full setup takes 1.1s: thousands of lines of elisp configuration.
I'm running the native-comp branch since six months (?): compilation of Emacs itself is a bit of a pain but running it is very smooth.
That's on a 6 or 7 years old Core i7 6700K / 16 GB of RAM. Hardly a speed demon (besides the NVMe M.2 PCIe 3.0 x4 SSD).
Configuration, IIRC, has got a few "tricks" to prevent the usual culprits from slowing Emacs: something to do probably with font-locking on very long lines (?) when I open such a file etc.
But it's overall more than snappy. I use ivy/avy/swiper and burntsushi's rigpgrep integrated into Emacs. Everything is not just fast but really fast.
I cannot even imagine on a modern machine like some AMD 5900X or Apple M1...
Switched over to VSCode with as many extensions as I could find to get me close to my Emacs setup (including edamagit) and it, to my surprise, was actually very productive. I've been using VSCode now for 6 months and 15 year old me in the 90s is very mad at current me for selling out.
I would guess if you have something like FlyMake configured for on-the-fly syntax checking, you could also get a "laggy" feeling.
Just launching and using a vanilla emacs session feels quite snappy in my experience.
I use the Vim plugin for IDEA and evil mode in Emacs. Even things like holding 'j' or 'k' to scroll lines is painful in Emacs compared to IDEA.
I'll admit that if I spend some hours/days in Emacs, I stop noticing it much, so it isn't THAT egregious. But if I switch back and forth, it really sucks.
I use emacs as my main editor, but as with all software it's easy to accidentally create situations where it gets laggy, regardless of hardware. Two that I've hit over the past 10 years: (1) On Windows only, movement of point in buffers with non-ascii characters lagged when said characters were visible due to frequent gc pauses. Was fixed by making emacs wait longer to do gc, and only when idle. (2) A theme that styled text with a box around it (customize-face) made buffer redisplay laggy. Not sure why; just turned it off.
Use case: open a yaml file with syntax highlightning, scroll it with the mouse. The latency should be as low as possible.
Even better when you can actually hop into conflicted files and use smerge and language-specific tooling (LSP) to do "real IDE" stuff.
From what I gather, mainline Emacs was adversely impacted by changes in Mojave. [2][3] The end result, for me, is that any gains in the native compilation are swamped by the macOS issues. I'm hoping that Mistuharu rebases his work on the native-comp Emacs soon, so that I can get the best of both.
[1] https://bitbucket.org/mituharu/emacs-mac/src/master/
[2] https://www.reddit.com/r/emacs/comments/faz1fm/seeing_a_flas...
[3] https://emacs.stackexchange.com/questions/59966/is-it-possib...
What’s your setup like? I’ve experienced some lagging from time to time—almost always because I turned on some package I didn’t need. My thirst for responsiveness has won out and now it’s nice and snappy.
I’m personally not running the native-comp branch, but I hear lots of people say it’s a game changer. Native-comp recently got merged to master, so when Emacs 28 ships it should be available to everyone!
I really want Edamagit to work. I'm still getting my feet wet with VSCode but Git integration is a bit of a pain.
[1] https://www.emacswiki.org/emacs/GuileEmacs
I think a full rewrite in any language would have likely brought about a better UI experience.
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 level of complexity.
[1] https://savannah.nongnu.org/projects/quilt [2] https://stacked-git.github.io/
wonder what kind of projects do you use
It looks a bit like a menu-based GUI, so you'd expect to navigate around and use a standard set of keys, but most of it is actually powered by special key combinations.
Now, in some circumstances, that works fine, but honestly the interface could be simplified a bit and probably made faster to use. And less prone to the "oh shit, I thought I was typing something but now I actually hit 3 different Magit key combinations and have no clue what just happened".
Personally, I'm hoping someone takes the standard VC thing in Emacs and adds some of the Magit features to that. But meanwhile, I'm using Magit. :)
Yours has been literally the first negative comment out of hundreds of comments I've read about magit. It'd be interesting to learn what didn't work for you and why.
This is (in my opinion) terrible advice, as you need to be a fairly competent emacs users to use magit, else you will keep hitting weird situations you can unable to escape (as you don't know the emacs thing to do).
For everything else I absolutely love magit. The ability to stage and commit chunks in a visual fashion is an unbeatable killer feature!
The submenus are also a bit overwhelming. I just wanted to stash my working tree, not be given dozens of options for how to stash! Emacs already has a way to signal that you want to give an option to a command, so this interface feels very un-emacsy. "M-x magit-stash" should just do the common thing imo. C-u M-- prefix if I want something fancy.
Another time, I fat-fingered a branching operation, and I spent a good five minutes trying to figure out how to fix it within magit, and then gave up and solved it in 30s from the cli
I just gave it a try:
magit-blame seems hard to read, I guess it's a limitation of emacs, or can it be configured to show the author name on the left of the line like CLI git blame?
I tried to find the equivalent of "git add --patch", but did not find it in the info manual.
What kind of race car stuff does git CLI offer that makes you have to go through weird contortions in magit :)?
Just practice, practice, practice. I can attest that the benefits are worth your while (if you use git daily, at least).
Note that you can run raw git commands by pressing : in any magit buffer. It opens a commandline prepopulated with `git `, so you can type whatever you want afterwards. The output will appear in the relevant `magit-process` buffer.
(The choice of : is analogous to M-: which will execute an Emacs Lisp expression)
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 I'm not sure they will ever be able to keep up with all the development that has been happening on Emacs
I just open up a log view to the branch i'm cherry-picking from, move the cursor to the commit I want to pick, then if I don't remember what the key is I just press ? and it shows me all the commands, then I press A for cherry-picking, and it immediately populates it with the commit that my cursor is on in the log view. Easy-peasy.
I am using emacs on a Mac, often with a 4K screen, and generally have no problems. I did have a scrolling lag issue a few months ago, but it was because of a bit of code that I had added to my modeline that was doing way too much work every time something changed in the buffer. The profiler pointed me right to it.
Emacs is at least an order of magnitude more responsive than IDEA (or any other JetBrains IDE). Start with a stock Emacs, no extra third party packages loaded, to get a sense of performance. There is a lot of great Emacs Lisp code out there, but the opposite is also true: Horrible code written by folks new to Emacs and Emacs Lisp, that can slow down Emacs a lot and contribute to a degraded experience. Which is why I recommend starting from scratch and incrementally adding third party code/configuration (ideally, understanding the code as you go along and avoiding packages with lots of dependencies).
I know, for example, that a lot of people who have tried both report that Doom Emacs is much faster than Spacemacs. That implies to me that it's not evil mode. For my part (fairly vanilla Doom setup), I find holding j/k to scroll in Doom is snappier than IntelliJ, on the same computer.
But then, I've also heard people complain that it's just the opposite on Windows, where Doom emacs is apparently just really laggy.
That said, I agree that the "works for me" discussions aren't very fruitful, and I'm definitely not here to tell you which editor to use. More observing that, what with how... emacsy... emacs is, you're definitely not alone. It's entirely possible that the problem you had is both something specific to how you had things set up, and also absolutely not at all your fault.
https://www.gnu.org/software/emacs/manual/html_node/emacs/In...
EDIT: okay dozens overall, < dozen simultaneous
1. Check out target branch
2. l o (log other) source branch
3. Highlight commits from list you want to cherry pick.
4. A A to apply the pick (I typically throw a -x flag into there too)
Also, dang I miss coding in TS instead of Go.
So it's really 100% on me for not being an emacs native rather than any shortcoming of magit per se, and as I said at some point I'll probably invest the time, but I _already_ have muscle memory for working in my terminal.
Yeah, otherwise you're not comparing apples to apples ;)
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: "
You're right, but I think they are not limited to it. Stgit has a command to directly convert patches to commits. Quilt deals only with patches. So the patches will have to be applied to working tree before they can be committed.
> I want to be able to highlight a change to the workdir, hit a key and select a local commit
> I just discovered today that intellij has the concept of named changesets (i.e multiple staging areas, and you select 1+ to commit).
I am still learning stgit, but I think this is what stacked patches essentially achieve. The patches can effectively be used as multiple staging areas. You can design multiple commits simultaneously and commit them independently. Here is my novice assessment of that workflow: https://gitlab.com/-/snippets/2126398
> 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)
That sounds like interactive staging (`git add -p` or `git add -i`). You can do the same in magit, in the status window by selecting the diff lines you want to stage. I use evil-mode and use visual mode for that selection. Am I missing something about your requirement?
At least in magit, you get the error "new file ... depends on old contents" if you try to stage a hunk of a newly created file.
(i.e. echo "foo\nbar" > file, then stage only "bar")
There are different styles available. While blaming a file, press B to open the popup, then c to cycle through them.
> I tried to find the equivalent of "git add --patch", but did not find it in the info manual.
That's just the entire staging workflow. You see a list of changed files, which you can stage per file. Or you can expand a file to its changed chunks using TAB, then stage chunk by chunk. Or you can select some lines in the chunk and stage only those.
If the Cocoa port runs well, well that changes everything to me
Opening a very large file?
Edit: I have found that if I don't reboot my Mac, the environment that a launcher emacs finds is sometimes off. Is it the same slow if you launch from a terminal versus the dock?
I'm using Doom with pretty much default settings. Perhaps there's something heavy there.
Basically even doing something mundane like C-n/C-p in a dart-mode buffer takes up a lot of memory (~800mb), which causes very high GC pressure and everything visibly stutters. Here is the `profiler-report` output just now:
https://paste.gnugen.ch/paste/5zED
But it's not helpful beyond pointing out that `line-move` when called from `next-line` for some reason is memory intensive.
you could maybe try the two lines here (set the megabyte count, the third number, to your own liking): https://emacs.stackexchange.com/questions/34342/is-there-any...