EAF Git Client [Emacs高性能 Git 客户端]

我平常的Git操作比较简单,又非常懒,懒的敲一堆Git命令,下面是我整理的平常用的Git操作。

我最近在构思要不要利用EAF写一个简单的Git客户端,主要解决以下问题:

  1. 性能:默认会用 libgit 库结合Python多线程解决启动速度和耗时操作卡顿(比如查看所有日志)
  2. 简单:magit 其实非常强大,对于Git专家来说很好用,但是对于我这种基础用户来说还是太复杂了,我希望基本操作傻瓜化,复杂操作我干脆直接上命令行了
  3. 友好:EAF支持多媒体界面布局,像平常日志列表,命令辅助都可以在一个界面中显示,不需要现在 magit 有时候还需要弹一堆 key menu
  4. 集成:比如文件 diff 查看和操作的时候还是结合Emacs的强大功能,需要时分屏弹出Emacs Diff窗口操作

平常大家都是magit用户,我有时候觉得这玩意还是太重太复杂了,大家觉得这个方向是对的吗?和大家讨论一下。

7 个赞

EAF去年曾经写了一个Git Client, 中途删除了,主要原因是那时候还没有打通 Elisp 和 Vue 之间的互调用问题,编程很麻烦,同时当时想直接用EAF解决所有操作,但是Diff相关代码在Python端编写太复杂。

今天重新梳理了一下:

  1. 新的Git客户端定位频率最高的简单操作,复杂操作丢给终端
  2. Elisp 和 Vue 的互调用在EAF文件管理器开发中彻底解决,现在没有障碍了
  3. 针对Diff相关操作,可以采用分屏的方式和Emacs内置的Diff模式协作,灵感于EAF RSS阅读器

个人倾向是 client 最好能简化复杂操作。简单命令我是能接受手动敲的(这要归功于zsh-autosuggestions和zsh-history-substring-search)。

我用 magit 的原因是最近频繁用 git rebase -i ,这个手动的话要先 log 查看 commit id 然后才能继续操作。magit提供一个dashboard就能很方便选中 commit 然后 rebase。

另一个是 blame ,现在 magit 的 blame 只能说是勉强够用,但是显示效果实在不怎么样,甚至不如命令行。

所以我认为magit虽然重但确实是能简化一些复杂操作的。如果现在新的 client 不支持复杂操作的话那么dashboard的表现力会更重要,这正好也是EAF擅长的。

3 个赞

或者大家说一下最常用的git操作或最需要工具辅助的复杂操作。

我要先想好再写,避免上次那种没想好最后又删了。

常用又比较需要工具辅助的可能也就rebase、blame和冲突处理了。虽然magit繁杂一点,但是确实是功能多且好用,目前我遇到的唯一痛点应该还是magit展开过大的diff的时候,容易卡。

我主要对 magit 用菜单相互关联的连续操作头晕,可能和我Git命令操作也不流畅相关吧。

对我来说最需要工具辅助的(目前我还没有找到好的解决方案的)是

  1. 快速搜索 commit message。尤其是在只大概记得几个关键词的情况下,在 magit 里搜索比较繁琐,需要重复用相同的命令搜索。
  2. git clone。说实话每次需要 clone 一个仓库的时候我都是在命令行里操作的。

第一个搜索commit的原因是啥?没看明白

我不知道我在这方面算不算特殊,我其他时候比较喜欢命令行,唯独在 git 这里我有点怵命令行,因为子命令和 flag 太多。以前用 vim 的时候用的 fugitive,所以切到 Emacs 以后用 magit 没有任何不适,而且马上就发现 magit 好用的多。配合上 ediff 处理冲突,中间用 transient 的菜单衔接 (继续或者取消之类的) 一整套流程下来,感觉方方面面都照顾到了。这要是用命令行,我估计我这种笨蛋一次性成功的可能性不会太大。

说到「重」的话,我觉得这不是 magit 的问题,是 git 本身越来越重了。而且 magit 是少有的那种我完全不介意他重不重的那种 package,因为我每次用到一个新的特性,都有一点相见恨晚的感觉。

所以如果 EAF 的 Git Client 不想做大而全的那种,我个人觉得正如前面各位说的,干脆就发挥最擅长的部分,比如处理大的或者二进制的 diff (像 github 可以直接比较新上传的图和旧图我觉得很有用)。

3 个赞

EAF Git Client 我最想要做的就是按照场景来指导我自己操作,我实在记不住那些命令,但是我需要有一个工具告诉我每个场景怎么去做。

Magit主要靠很多模块串联,对于我来说痛苦的是,我从学习 git 各种命令切换到学习magit各种界面的快捷键记忆,我主要想面向Git初级用户搞点傻瓜化的操作,提升我日常的效率。

大的二进制 diff 这种能举个详细的例子吗?比如你怎么操作,你期望怎么样的结果?

对,场景化是很重要。所以我也没有记过 magit 的命令,我就是掌握几个「场景」关键词,比如 c 是 commit, l 是 log, r 是 rebase, p 是 push 之类的。如果要控制场景下具体的细节就先无脑按那个键,子菜单就告诉我了。用的次数多了我发现我就不需要菜单了。就变成一些类似 cc (commit), ce (commit extend), P-fp (看上去很复杂其实就是force push) 的操作。

就是在 github 上点 commit 不是可以看到图片吗 类似这样

我印象里 magit 是看不了的,而且如果这个图很大好像还会卡住。

我现在的障碍就是记这些magit连续快捷键非常头疼,我想根据场景化的设计,把我经常用的那些连续命令变成一个按键,告诉我按一个按键就行了,我不想 magit 弹出那些菜单,然后再一直按,真的记不住。

好,我看看怎么融入我的设计中。

那你这个懒可真是名不虚传哈哈

我喜欢强大的工具,但是讨厌复杂的用法,这也是我不断改进Emacs的原因。

5 个赞

如果没记错的话,magit的transient菜单操作完之后,也是对应到一个命令,是不是绑定下这些命令就可以了?

我日常通过命令使用的有 magit-clone 和 magit-log-buffer-file ,这两个我也不知道怎么按😹

忘了具体的使用原因了,大概是因为想看看跟一个功能有关的一些 commit message,这个时候只知道一些大概的关键词,用 magit 可以按 l-G 在 commit message 里搜索一个关键字,所以我需要不断按这个 keystroke 来搜不同的关键字。

利用多线程技术,将近3000多条Commit秒开,子线程扫描完所有Commit信息后才发送到Vue前端更新。

1 个赞