[HN Gopher] Magit 3.0
___________________________________________________________________
Magit 3.0
Author : mpsq
Score : 298 points
Date : 2021-05-25 09:17 UTC (13 hours ago)
(HTM) web link (emacsair.me)
(TXT) w3m dump (emacsair.me)
| the_duke wrote:
| Emacs is too laggy for me as my main editor.
|
| 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.
|
| [1] https://github.com/jreybert/vimagit
| MobileVet wrote:
| Have you tried Spacemacs w/ VIM bindings (evil mode)?
| unhammer wrote:
| Tried native-comp?
| https://news.ycombinator.com/item?id=24117853
| dhess wrote:
| I have, on macOS, and somehow, it has _much much worse_ lag
| than Mitsuharu Yamamoto 's Emacs "Mac port," [1] which is
| still based on Emacs 27.2. The native comp version was so
| slow that I gave up and switched back to Mitsuharu's port,
| which is snappy enough for my needs even without the native
| compilation bits.
|
| 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_f
| las...
|
| [3] https://emacs.stackexchange.com/questions/59966/is-it-
| possib...
| AlexCoventry wrote:
| Emacs 28 is much faster for me, on ubuntu, FWIW.
| michaelcampbell wrote:
| Where are you getting 28?
| https://mirrors.ocf.berkeley.edu/gnu/emacs/ only shows up
| to 27.
| nvarsj wrote:
| 28 is the current master of Emacs. So you have to compile
| from source.
| ashton314 wrote:
| > Too laggy
|
| 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!
| TacticalCoder wrote:
| 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 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...
| mtalantikite wrote:
| 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 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.
| wiredfool wrote:
| LSPs and Large JSX file highlighting seem slow to me.
| da39a3ee wrote:
| I have the exact same story. Multiple LSPs in emacs was too
| hard to manage and seeing as some of it was typescript,
| much worse than the VSCode experience. Edamagit has made a
| very good start at emulating magit in VSCode. Still use
| emacs for magit though.
| the-smug-one wrote:
| It's probably too late for you :), but I use native-comp
| Emacs and it's blazing fast. At least lsp-mode+gopls is.
| I haven't gotten the chance to use this setup with
| Typescript's LS, but I've used gopls+clangd without slow
| downs.
|
| Also, dang I miss coding in TS instead of Go.
| natrys wrote:
| I have the same experience. Being on master and
| nativecomp probably helps, and I also think eglot is tad
| smoother than lsp-mode. I am using 10 year old laptop, no
| friction at all with tsserver, elixir-ls or gopls.
| However I think the server itself is the biggest
| difference maker, because all hell breaks lose when I try
| dart/flutter even in a simple project. But to be fair, my
| neovim setup struggles with that too (nvim-lspconfig +
| nvim-compe).
| tngranados wrote:
| I think it's a Mac and an HDPI thing. I had to stop using
| emacs because it was too slow on my work MacBook Pro
| connected to a 4K screen. Scrolling was painful and only
| marginally better with nativecomp.
| b3morales wrote:
| If you are interested in continuing to use emacs, I'd
| suggest using the profiler to investigate. There's a good
| demo/depiction of doing that here:
| https://www.murilopereira.com/how-to-open-a-file-in-emacs/
| (posted recently to HN). I think it's most likely to be
| something pretty specific/small in the config you're using.
|
| 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.
| darthrupert wrote:
| Perhaps this is about MacOS vs Linux. I'm also suffering from
| slow emacs on mac, and no combination of flags seems to help.
|
| Use case: open a yaml file with syntax highlightning, scroll
| it with the mouse. The latency should be as low as possible.
| nvarsj wrote:
| It's most likely a Mac thing. And is probably the main
| reason I gave up on OS X as a serious work OS, since I'm so
| dependent on Emacs (org-mode in particular). I hope it gets
| sorted one day. Apparently it has to do with certain system
| calls on OS X just being very slow.
| ryukafalz wrote:
| This is my experience as well. I know it can be fast
| because emacs absolutely screams on my Linux machines, but
| it's super sluggish on the Mac I have to use for work.
| dpbriggs wrote:
| Emacs on MacOS was also laggy for me before I started using
| the native comp feature. It takes a while to compile but
| it's seriously one of the best QoL changes I've had in
| years.
| chalst wrote:
| I have a very underpowered Macos machine (2010 Mac mini)
| which faces latency problems with most things. Except
| Emacs. E.g., Eshell is much snappier for issuing shell
| commands than bash on iTerm2.
| taeric wrote:
| Fwiw, I'm not seeing lag on my end doing the same. Can turn
| on magit blame and it still scrolls fine. :(
|
| 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?
| darthrupert wrote:
| No, not very large.
|
| I'm using Doom with pretty much default settings. Perhaps
| there's something heavy there.
| taeric wrote:
| I don't think anyone really wants to profile their
| editor. That said, if you have the cycles to spare, M-x
| profiler-start, scroll, M-x profiler-stop may have some
| obvious culprit.
| weavie wrote:
| I've recently had to dump Emacs for Vim. I found with using
| Rust Analyzer on Emacs, it would regularly lock up for a
| number of seconds. With Vim (NeoVim anyway) this does not
| occur.
| Tehchops wrote:
| 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.
| Decabytes wrote:
| 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 I'm not sure they
| will ever be able to keep up with all the development that
| has been happening on Emacs
| Tehchops wrote:
| Yea, it's quite unfortunate. Magit and Org-mode are
| killer, and don't really have 1:1 equivalents anywhere
| else.
| throwawayboise wrote:
| Emacs is still (AFAIK) entirely single-threaded. If you are
| performing some operation that blocks (e.g. a network call, a
| shell command such as "git clone") all other windows are
| blocked until that completes.
|
| 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.
| d0mine wrote:
| you don't need multiple threads to run things concurrently
| (such as network I/O, communicating with subprocesses)
| e.g., I believe url-retrieve in emacs doesn't stop the
| world (because there is -synchroniously version too). async
| is a thing
| spamizbad wrote:
| Likely an OSX user. Emacs on my 2018 MBP is noticeably slower
| than my 2016 Dell XPS running Linux - despite the MBP having
| more ram, more clocks, and more cores.
| jpeloquin wrote:
| > How comes Emacs is laggy for you?
|
| 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.
| ragnese wrote:
| I know that these "works for me" discussion are often not
| fruitful. But, I'll ask this: have you done a several hour
| session of typing/programming into a JetBrains IDE? I'm
| claiming that on my work Macbook Pro, even just typing plain
| text into a file and scrolling lines in IDEA is smoother and
| more responsive than doing the same in Emacs.
|
| 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.
| michaelcampbell wrote:
| Is it possible that your vi plugin is introducing some lag?
| mumblemumble wrote:
| It's really hard to tell. The configurability of emacs is
| both a blessing and a curse. Since you can customize
| basically anything, there are all sorts of opportunities
| for funky config or a weird extension to slow things down.
|
| 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.
| metroholografix wrote:
| Something is definitely wrong with your configuration (in a
| wide sense, not necessarily restricted to just the editor).
|
| 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).
| gpderetta wrote:
| Personally, I find that normally emacs latency is more
| than tolerable. But LSP is pretty bad, at least with
| clang-lsp, especially on a fairly loaded machine. I have
| yet to try the jit branch though.
| creese wrote:
| If you're using HJKL to navigate more than a few lines,
| you're doing it wrong. Use 'search' instead.
|
| https://www.gnu.org/software/emacs/manual/html_node/emacs/I
| n...
| agumonkey wrote:
| > Emacs is too laggy for me as my main editor.
|
| wonder what kind of projects do you use
| iib wrote:
| Can you try `lsp-doctor` and try to resolve any performance
| hints it outputs? The latest `lsp-doctor` seems to also know
| about the native compiler, so one less thing to worry about
| when checking.
| Steltek wrote:
| Likewise with VSCode, Edamagit is very close but isn't "muscle
| memory" close. I run into things that aren't quite the same as
| the original: choosing a remote on a new repository when
| pushing or selecting switches using the VSCode native pop-up.
|
| I really want Edamagit to work. I'm still getting my feet wet
| with VSCode but Git integration is a bit of a pain.
| ragnese wrote:
| Yeah. I still use Emacs for actual development sometimes, but
| it's been less and less, honestly. But it isn't going anywhere
| as my git porcelain. I used to scoff at even the _concept_ of a
| git porcelain- I never used my IDEs ' tools to do git ops
| because I thought they were weird, leaky abstractions, and that
| you just have to learn "real" git anyway. But Magit doesn't
| hide git from you- it's just a really nice, interactive,
| interface over git.
|
| Even better when you can actually hop into conflicted files and
| use smerge and language-specific tooling (LSP) to do "real IDE"
| stuff.
| xvilka wrote:
| They could have solved this with porting from single-threaded
| Emacs Lisp to Guile[1] or a proper Common Lisp[2]. Sadly, both
| initiatives didn't get enough steam. Someone, though, started
| to rewrite Climacs in SBCL from scratch[3].
|
| [1] https://www.emacswiki.org/emacs/GuileEmacs
|
| [2] https://www.cliki.net/cl-emacs
|
| [3] https://github.com/robert-strandh/Second-Climacs
| ragnese wrote:
| I'm not convinced that Elisp-the-language is really the
| limiting factor. I'm not an expert on the details- just a
| passive observer for several years. But, IIRC, Elisp recently
| got some kind of cooperative async stuff. Even before that,
| my understanding was that there are a lot of legacy
| architecture issues with Emacs, from its GUI model to the
| actual text data structures, that contribute to to
| latency/slowness.
|
| I think a full rewrite in _any_ language would have likely
| brought about a better UI experience.
| lawn wrote:
| I agree. At work we use Windows and all the dev tools are
| integrated to Emacs (and Emacs alone). And magit is just
| _incredibly_ slow.
| TeMPOraL wrote:
| I had some performance issues with Magit (and git in general)
| under Windows, but ultimately resolved them. I documented the
| solutions here:
| https://news.ycombinator.com/item?id=26736006. Maybe some of
| it will work for your case.
| rjzzleep wrote:
| I find magit cool, but I always find myself going back to using
| tig or !tig (combined with git add -p for interactive adding)
| inside of vim. It's a lot faster of all the editor extensions
| for me.
|
| [1] https://jonas.github.io/tig/
| iudqnolq wrote:
| 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 level of complexity.
| sreevisakh wrote:
| 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/
| iudqnolq wrote:
| 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: "
| [deleted]
| karl42 wrote:
| I'm really happy with fugitive[1] for vim. Can anyone compare
| those two well enough, so that I understand what I am missing?
|
| [1]: https://github.com/tpope/vim-fugitive
| poidos wrote:
| Congratulations to Jonas and the whole team! Magit is a joy to
| use and has made me feel supremely comfortable with advanced git
| work.
| globular-toast wrote:
| Not to detract from Jonas's efforts in the slightest, but the
| original author, Marius Vollmer, deserves a lot of credit for
| coming up with the UI for magit. There weren't any other emacs
| packages quite like it at the time.
| nonbirithm wrote:
| I 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-status take 10 seconds per
| refresh/stage/unstage instead of half a second elsewhere. It got
| to the point where using the git command line was much more
| bearable, but way more error-prone, and I miss Magit every time.
|
| https://magit.vc/manual/magit/Microsoft-Windows-Performance....
|
| https://github.com/magit/magit/issues/2959
| dan-robertson wrote:
| 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?
| jackewiehose wrote:
| > isn't process creation more reasonable with WSL?
|
| In my experience WSL is overall much slower than cygwin.
| jackewiehose wrote:
| 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).
| mekster wrote:
| How does the interface compare to SourceTree?
| globular-toast wrote:
| It's in a different league. Hard to explain to a non-emacs
| user, though. Which is a tragedy because I'd love to explain,
| but some things just have to experienced.
| tcoff91 wrote:
| Magit is like using the terminal client but easier. You have to
| press fewer keys to do things, and it makes the various
| operations discoverable through menus. It's really the best way
| to interact with git IMO. However, if you don't use Emacs
| already it's a little much to setup Emacs just to use Magit.
|
| 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/
| dreamcompiler wrote:
| Magit is designed for people who are already used to the git
| command line. Sourcetree is not.
|
| 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.
| bm3719 wrote:
| Magit is definitely one of the best addons for Emacs.
|
| Nice to see Forge getting some attention. One less reason to ever
| leave Emacs is always welcome.
| bgorman wrote:
| When I switched to emacs, I thought org-mode and repl integration
| would be the killer features. I was wrong- Magit is best emacs
| feature by far.
|
| 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.
| globular-toast wrote:
| I love git but every time I have to use the cli instead of magit
| I cry a little.
| omaranto wrote:
| When do you have to use git rather than magit?
| globular-toast wrote:
| Mostly helping others fix their mistakes on their machine.
| omaranto wrote:
| 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.
| ta988 wrote:
| Magit is really one of the best git interface there is. I'm often
| coming back to it.
| chewxy wrote:
| I ran `magit-version` and I got Magit 20201225.4, which I assume
| is the 2020 Christmas edition of Magit. Did they suddenly switch
| to semver?
| 2pEXgD0fZ5cF wrote:
| You are probably using melpa instead of melpa stable (like
| most, I assume). In melpa, all packages use the yyyymmdd.x type
| of versioning. In melpa stable packages use semver.
|
| Have a look:
|
| https://melpa.org/#/magit
|
| https://stable.melpa.org/#/magit
| cstml wrote:
| Fantastic.
| aryamaan wrote:
| I never fail to see so many high things about Magit and I believe
| they are rightly placed.
|
| I am a non Emac user and wonder why no one tries to bring
| something similar client for non Emac population.
| MobileVet wrote:
| It really is fantastic... and for the non-Emacs folks like
| myself you can run it in Spacemacs w/ VIM bindings (aka evil
| mode).
| jidiculous wrote:
| there's an effort to replicate Magit in VS Code:
| https://marketplace.visualstudio.com/items?itemName=kahole.m...
| trentontri wrote:
| when can we stop renaming 'master'? it's a pointless update.
| mumblemumble wrote:
| I'm not sure you understood this change?
|
| 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.
| amackera wrote:
| Magit hits the sweet spot between flexible and easy that makes it
| an actually useful git editor integration. You still need to know
| git to use it, though!
| NeutralForest wrote:
| Magit is one of the best piece of software for Emacs! Good stuff
| =)
| jhvkjhk wrote:
| I heard lots of praise to Magit. Is there a way to use it like a
| standalone git client? Like tig, lazygit, etc.
| ashton314 wrote:
| You could just alias this in your shell:
| alias magit='emacs -nw --eval "(magit-status)"'
| jhvkjhk wrote:
| Thanks, that's exactly what I want.
| iib wrote:
| I was reading the thread and replied to a very similar
| situation. The only addition was that if you want only a
| magit interface, it makes no sense to load the rest of your
| emacs config, so you could add a special magit initialization
| file, and just add -Q --load magit-init.el
| dmm wrote:
| Sure, just open the git repo in a magit. I do it almost every
| day.
| codemonkey-zeta wrote:
| Did you mean "open the git repo in a magit buffer"? Because
| then I'd agree.
|
| To address GP comment, you can just install vanilla emacs,
| then install magit, and just use that as your "standalone"
| app.
| globular-toast wrote:
| Honestly, you'd only get a fraction of the power of magit doing
| it that way. It's power is due to it being thoroughly
| integrated into the environment you use for editing all kinds
| of text every single day. Imagine being able to control git
| using the same commands your used to in whatever text editor
| you use.
| CJefferson wrote:
| I would strongly recommend first doing some emacs tutorials --
| you don't have to start using emacs as your editor, but (in my
| opinion) magit does assume you have some understanding of how
| emacs works.
| divs1210 wrote:
| Magit 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
| iib wrote:
| Would the need for a pure terminal magit be resolved by the
| fact that Emacs can run in the terminal? [1] seems to have a
| solution to obtain a fast starting subset of Emacs and start
| into magit-status directly. emacs -Q -nw
| --load magit-init.el --eval '(progn (magit-status) (delete-
| other-windows)'
|
| Would this work in IDE consoles?
|
| [1] https://www.wisdomandwonder.com/article/10787/emacsorg-
| mode-...
| [deleted]
| codychan wrote:
| You haven't touched its core code for two years, what happened?
| Gave it up?
| medstrom wrote:
| He/she's no longer using IntelliJ.
| tephra wrote:
| I usually always have Emacs up and even if I'm in vscode or
| intellij I use magit in Emacs for all got things.
| dang wrote:
| Some past related threads:
|
| _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)
| zelphirkalt wrote:
| Looking 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 arguments are I am
| specifying by a few key presses actually are. If it made me
| forget how to use actual git, I would be thinking: "Meh, but I
| should know how to use git actually, for the times when I do not
| have magit around." Fortunately this is not the case at all with
| magit.
| Steltek wrote:
| Magit has a great mix of direct manipulation of git primitives
| and good visualization. I think I've learned how git works
| faster through Magit than I would have from using the CLI. It's
| really hit a sweet spot for me.
| lambdaba wrote:
| This is what I'd want from any GUI, ability to "view source"
| and then use in scripting etc.
| TeMPOraL wrote:
| I'm sure you know this, but for the benefit of other
| readers, pressing '$' in Magit status buffer (and likely
| bunch of others) pops up a buffer that lists actual
| commands issued to Git, so you can always check how Magit
| interaction maps to Git CLI commands.
| neves wrote:
| Nice. I think the same about the GUI gitExtensions.
|
| I'll give it a try
| willtim wrote:
| > "git at the speed of thought" describes magit quite well.
|
| Not under Windows, unfortunately.
| Decabytes wrote:
| Magit is incredible and Emacs is my main Editor. Reading the post
| a couple days ago on text selection and how hard it is to get
| right makes me even more in awe of what a text editor does
| aidenn0 wrote:
| I haven't tried very hard yet, but magic has been fairly
| unintuitive for me. Perhaps it's just that I've been using git
| for so long.
|
| 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
| b0afc375b5 wrote:
| Hang in there. I was a beginner at magit (and emacs, to boot)
| and had to keep at it for a few weeks before it became
| intuitive for me. I also had to google how to push and fetch
| and revert every time, because I would keep forgetting it. And
| emacs keybindings was weird to me at the time, since I was used
| to vim keybindings.
|
| Just practice, practice, practice. I can attest that the
| benefits are worth your while (if you use git daily, at least).
| pmoriarty wrote:
| Do you remember what you tried?
|
| 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.
| warp wrote:
| My experience is the same. Probably because I'm so used to
| git on the command-line already magit doesn't seem much
| benefit.
|
| 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.
| jorams wrote:
| > 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?
|
| 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.
| aidenn0 wrote:
| The first odd thing is that magit runs in emacs' working
| directory, rather than the directory of the buffer you launch
| it in (my experience with most emacs commands is that they
| will take the cwd from the buffer). I'm going to have
| multiple git repos, and I usually only start emacs once, so
| this gets me almost every single time.
|
| 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
| coryrc wrote:
| Magit always opens to the buffer's repo IME. I use dozens
| of repos simultaneously so I experience it daily.
|
| EDIT: okay dozens overall, < dozen simultaneous
| CJefferson wrote:
| I didn't like it, I have several friends who tried it and
| didn't like it. The main problem (for us) was that people
| said "Hey, this is so great you should use it even if you
| don't use emacs".
|
| 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).
| aidenn0 wrote:
| I use emacs and still struggled with it. The interface is
| not particularly emacsy.
| drunkpotato wrote:
| Cherry pick is faster and easier for me in the CLI. I've read
| Magit's documentation on Cherry pick dozens of times and I
| still have no idea what it's doing. I think I have
| successfully done it in magit once, but now I don't bother
| and just do it on the command line.
|
| For everything else I absolutely love magit. The ability to
| stage and commit chunks in a visual fashion is an unbeatable
| killer feature!
| SirensOfTitan wrote:
| I do cherry picks in magit by:
|
| 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)
| drunkpotato wrote:
| Thank you! That workflow makes sense. We'll see if I
| remember that next time I Cherry-pick.
| anyonecancode wrote:
| I've had the same experience. I've been using org-mode as my
| primary note-taking tool for several months now and am getting
| more comfortable with emacs as a result, but while I can see
| the appeal of magit, the "spend time learning how emacs git" vs
| "use the CLI to do what I want in 3 s" hasn't balanced out yet
| in magit's favor. At some point I'll probably sit down and take
| like a half day or so to actually learn magit, but git CLI
| isn't really broken for me so the drive to learn an alternative
| git tool hasn't been all that strong. Still, magit seems nice,
| so one of these days I'll probably make the effort.
| the-smug-one wrote:
| How often do you guys do really crazy stuff with git? I do
| some rebasing (interactively and not) and some cherry
| picking, very rarely do I touch reflog (in which case I do
| use the CLI).
|
| What kind of race car stuff does git CLI offer that makes you
| have to go through weird contortions in magit :)?
| anyonecancode wrote:
| Well to use magit, first it's "ah, how do I open magit
| again?" Then it's "crap, now my org-mode buffer has been
| replaced by magit when I really wanted it in a separate tab
| but forgot to do the right key combo for that", then 5
| minutes of googling "how to go back to previous screen in
| emacs doom", then remembering it's called a "buffer" That
| kind of stuff. I still get thrown off a surprising number
| of time by fat-fingering something and my emacs doing
| something surprising that I don't understand and am not
| sure what keys I touched to make it do that, and being
| unable to go back easily.
|
| 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.
| chriswarbo wrote:
| > I just dropped into a shell and did everything with the git
| command line
|
| 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)
| olau wrote:
| Magit is not terribly intuitive.
|
| 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. :)
| nvarsj wrote:
| There's definitely some aspects of it which I struggle with.
| Like cherry picking a commit always feels somewhat painful,
| and I can never remember offhand the exact menus and keys to
| press to do it. But for day to day development, it's fast and
| great. I love having the separation between the push branch
| and merge branches for example, which feels very natural in a
| PR workflow. And the forge integration is brilliant.
| tcoff91 wrote:
| Cherry-picking is amazing with magit. I use spacemacs so my
| magit has evil style keybindings.
|
| 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.
| nvarsj wrote:
| I think it's having to go into a log view that bugs me. I
| just want to press one button for cherry pick, point it
| to a ref and be done. It might be possible but I haven't
| figured out how yet.
| johndoe42377 wrote:
| This is a bloatware inside Emacs, while it should be a thin
| wrapper and a few modes.
|
| The whole point is to reuse Emacs APIs, not building up piles of
| crap with tens of dependencies.
|
| Enterprise software for Emacs lmao
___________________________________________________________________
(page generated 2021-05-25 23:01 UTC)