如题, 看到很多人说 magit 是他们最离不开的. 但我真的有些奇怪, magit 到底哪里比 git CLI 方便? 对我来说, 可以只 pick 一些 hunks 而不是全部, 这点很方便. 但其它的, 我真没太 get 到, 尤其是稍微大一点的 repo, 我感觉 magit-status 比 git status 卡太多了.
1 个赞
emacs 一个优点 是它的文本处理能力。 它可以将一段普通的文本变成可操作。
比如说 dired 基本就是对ls -l 的输出结果进行解析后,以纯文本的格式在buffer中进行展示
进而
当你在某个文件名上按下回车，则直接打开相应的文件，
你可以在这个buffer中用你熟悉的命令进行搜索、过滤、
甚至使用wdired-mode(writable dired）编辑buffer里的部分文本(如文件名、权限)进而实现改名、改权限的目的
magit 也是一样,它将各种git 命令的输出结果 变成可操作的。
比如 说magit 的 ll 查看的git log :
基本是 git log --graph --decorate --pretty=oneline --abbrev-commit --all 的输出
你可以在log 中具体的某个commit 上按下回车 查 看具体某个commit 的变更
可以在某个commit 上按下bb: checkout 这个commit
可以直接reset/revert 某个commit
可以在log中选中一段region,然后回车， 对region 开始与结束位置的两个commit 进行diff
magit-log-buffer-file: 查看当前buffer的commit log记录 ,在 log mode 中M-x:magit-find-file
则可查看此文件此commit时的完整文件内容
当然我对 此封装了一个命令 实现以下功能:
(define-key magit-commit-section-map [return] 'vmacs-magit-diff-range)
在magit-log-buffer-file 产生的log buffer中
return : 查看当前commit 的diff
有选择区域 则查看区域内的diff
C-u 则打开当前对应的版本的文件
vmacs/config/emacs/lazy/lazy-magit.el at master · jixiuf/vmacs · GitHub
(global-set-key (kbd "M-p") 'magit-blob-previous)
(global-set-key (kbd "M-n") 'magit-blob-next)
magit-blob-next/magit-blob-previous : (相当于 git-timemachine的功能) 则直接可以依次查看当前文件的历史变更
在git log mode 下 使用dc 查看具体某个commit 的diff时
可以通过 -b(Ignore whitespace changes) -w(Ignore all whitespace) 控制 是否忽略空格引起的变更
当然du 查看未提交的commit 的变更时 也可以使用-b -w 等选项.
我写了个toggle-diff-whitespace 用于在 magit-revision-mode/magit-mode 中一键控制 是否忽略空格的影响，对于golang 这种因gofmt 后造成大段变更的diff 很友好。
vmacs/config/emacs/lazy/lazy-magit.el at master · jixiuf/vmacs · GitHub
(define-key magit-mode-map (kbd "C-c Gw") #'toggle-diff-whitespace) ;gw
(with-eval-after-load 'diff-mode
(define-key diff-mode-map (kbd "C-c Gw") #'toggle-diff-whitespace)) ;gw
你感觉到卡 应该是在windows上用emacs 造成的体验相对较差。
15 个赞
magit好太多了，完全碾压命令行和其他git gui工具
首先不用自己敲命令；
然后有提醒功能，所有子步骤、子参数都有命令提示，极大降低了git的学习成本
在功能上又比其他的git gui工具强大很多
可定制性强
你说的卡顿，用native-compile会好很多，命令行只是会有即时输出，magit会在后台组织好再刷新界面，时间是差不多的
2 个赞
不下结论哪个好用，我列几个 Magit 让我非常“享受”的几个功能，希望能打动你：
magit-status 界面下可以直接选中代码区域进行 stage，非常符合直觉。使用 Git CLI 的话需要 git add -i
magit-commit 可以让我直接在 Emacs 中编辑 COMMIT MESSAGE，而且自动列出 diff，也可以很方便地查看历史记录。使用 Git CLI 的话，即使设置 EDITOR 也免不了要弹出一个新的编辑器窗口。
magit-cherry-donate：这个太好用了，可以选中某个区域的 commit 直接把它们嫁接到别的分支上，很适合在其他分支开发时想选中部分内容合入主线。
magit-rebase：在 magit-status 界面完成复杂的 rebase，非常实用。
magit-ignored-files：可以很方便地选择 private/global ignore。
…
总的来说 Magit 类似于 lazygit，更像是对 Git 的进一步封装，但是它的封装基本是“透明的”（得益于 Elisp 的扩展性），加上 Transient UI 的强大实用，从 Git CLI 过渡到 Magit 几乎毫无压力，甚至能让我从 Magit 封装的一些常见操作中掌握更多的 Git 最佳实践。
我原先使用 Vim 的时候也钟爱 Fugitive，现在使用 Emacs 便自然选择了 Magit，它们的特点都是将 Git 命令行和编辑器本身无缝结合了起来——写完代码，直接 C-c M-g s 然后 C-x M-g c c 编写 COMMIT MESSAGE，不需要反复在终端和编辑器之间切换，使得日常工作流更加完整顺畅。
当然，运行效率确实是 Magit 的硬伤，尤其是在远程编辑环境下。如果楼主觉得还是 CLI 更可靠、速度更快，那当然可以不使用 Magit。毕竟只是个工具，萝卜青菜各有所好。
8 个赞
除了Windows上卡，其他平台还好。Windows上igt本身也不快
1 个赞
卡的话，和windows有关，magit 的优势就是定制性高和作为gui集成的git功能相较于其他的客户端多，全面
magit 也就在 Windows 上比较慢，在 macOS是有点慢，在 Linux 下快如闪电。
期待 magit 加入 Emacs Core，同时能支持 libgit2 从而提升性能就完美了。
opened 04:35PM - 01 Feb 17 UTC
enhancement
area: abstraction
Magit's performance isn't so good to say the least. I would go as far as to say… that mediocre and in certain situations outright bad performance currently is Magit's biggest problem.
We have made some improvements in the past, like e.g. caching calls to `git` during a buffer refresh, but these improvements are to a large extend outweighed by the addition of new features. Already there exist useful features that are disabled by default because they can be to costly in some cases.
One major difference between Git and Magit is that the latter shows all kinds of useful information up-front. The major disadvantage of Magit's approach is that this information has to be always up-to-date (else it couldn't be relied on), and that doing so costs time.
To achieve good performance the cost of keeping (primarily, but not only) the status buffer up-to-date has to be reduced. And in order to do so, some fundamental changes have to be made. Doing that will take a while because it makes it necessary to replace some core abstractions. The good news is that improving or even replacing those abstractions will have other benefits beside improved performance.
---
**A** These are the primary causes of bad performance:
1. After the user has performed some action, the complete status buffer is refreshed. And that is done by recreating its content from scratch. Every time. All of it.
2. The required information is collected by calling `git` many times. Until recently, there was no alternative, but now Emacs has a foreign function interface and so we can start using `libgit2` now.
3. Expensive parsing (primarily diffs and logs) is done synchronously, even when we don't need the complete result immediately (because most of it is not visible until the user scrolls).
4. The results of expensive parsing are not being cached. (The result of calls to `git` are cached, but that mitigates the effect of (2), not (1).)
5. Many sections are created by inserting the output directly into the user-visible buffer, where it is then manipulated to look and feel the way we want to. Without changing that, it would be very hard to address (3) and (4).
---
**B** There are three primary paths for improving performance:
1. #2959 Start using `libgit2` instead of calling `git` over and over again.
2. #2985 Completely change how sections are created (using separate parsing-buffers, which likely will be preserved as a caching mechanism) and make it possible to update sections asynchronously and independently of the containing buffer.
3. Closely related to (2), only update those parts of a buffer that actually need updating.
4. Delay updating buffers that are not visible.
5. Insert diffs in two steps. Get a list of the modified files. For files that are expanded get the actual diff and insert it.
Luckily these two paths can be tackled in parallel, because in most cases a given section is **either** created by inserting and then "washing" `git` output (A5) **or** by processing a list of items (or a single value) using Elisp and then inserting that as the sections content (A2).
So aside from this overview, these changes will also be discussed independently, in dedicated issues.
opened 02:03PM - 12 Jan 17 UTC
enhancement
area: abstraction
*This description was taken from #2956. I intend to replace it with a more in-de… pth description at a later time.*
Magit is slow and part of fixing that involves the use of [`libgit2`](https://libgit2.github.com/), "a portable, pure C implementation of the Git core methods provided as a re-entrant linkable library with a solid API, allowing you to write native speed custom Git applications in any language which supports C bindings." Unfortunately nobody has written that for Elisp yet and since improving performance is a top priority now, I'll to it.
This will be named just `libgit.el` (or `libgit2.el`) and be pretty basic, i.e. just expose the functions provided by `libgit2` to Elisp.
---
Older discussions: #2539, https://github.com/magit/magit/issues/2442#issuecomment-165093660, https://github.com/magit/magit/issues/1327#issuecomment-39678570. (Yes, this goes back a while, but note that doing this is only even possible since Emacs v25.1, which was released in September 2016.)
---
Some resources:
- In depth documentation https://phst.github.io/emacs-modules
- Another list of resources https://github.com/emacs-pe/emacs-modules
- A simple module, also with links http://kitchingroup.cheme.cmu.edu/blog/2017/07/08/Adding-numerical-methods-to-emacs-with-dynamic-modules
- Emacs, Dynamic Modules, and Joysticks http://nullprogram.com/blog/2016/11/05/
And of course...
- libgit2 API https://libgit2.github.com/libgit2/#HEAD
1 个赞
最像 lazygit 的应该是 eaf-git GitHub - emacs-eaf/eaf-git: Fully multi-threaded git client for Emacs
magit 虽然很强大， 但是学习曲线太复杂， 它的组合性导致一些常用的git命令使用要人工记录一长串快捷键
2 个赞
其实我感觉完全不用记
例如 magit-commit，不仅列出了常用的 git commit 的参数，而且还附带解释，感觉和命令行里用已经没差了，还少打很多字 Edit HEAD 里的三个 action 对应的是常用的几个命令：
# extend
git commit --no-edit --amend
# reword
git commit --amend --only --allow-empty
# amend
git commit --amend
这些命令只要在 magit-status 界面下敲两个键就行了，或者在任意 git 管理的 buffer 下 C-c M-g c，非常方便。
Lazygit 依赖终端，我觉得还是跟 Git CLI 没差。Eaf-git 打算换 Linux 的时候试一下
1 个赞
功能最全的应该是magit和gitui，都是跨平台的
题外话，Windows上的Emacs对文本内容加密功能支持还需要一番折腾，不如Linux版浑然天成
我其实是通过magit学到了git的很多操作方式。哈哈哈
1 个赞
我也是，很多命令的参数也是通过magit学到的，也没有觉得学习曲线很陡峭
1 个赞
我从一开始就用的magit，第一眼就意识到它更有交互性和更简洁。思维上已经习惯只考虑要做的是什么操作，而不是要打什么命令。之前我拿magit操作完，要告诉同学怎么重复操作时，我还得去log buffer里找真实的git命令（
2 个赞
magit 最大的成功之处是自然就会用，即使命令行不熟悉。要深入查看log也能学习到。总结起来就是入门容易，深入也不难。
3 个赞
elx123
2024 年7 月 27 日 19:47
19
最大的优势是统一工作环境, 你没必要在git 和 emacs 中来回切换了, 单纯比较两者谁更好用没意义
magit比那些git教程教我的命令多多了- -
遇到好奇的就按下 $ 看看是啥
，因为它的快捷键就是命令行下的参数，而且还会有个 Transient UI 弹出来提示你，有时候脑子抽了看一下提示就行了。
。下方 
。