从 Vimium 转到 Vimium C

> 跟用的 git 命令、还是 TortoiseGit 图形界面，在这个功能上是没有区别的

> cp mv 这种应该是属于同一类基本操作，要是 git 以前能明确显式的支持 cp 命令，后面这个修改复制的文件后再提交导致的不能关联的问题，也就会不存在了

纯粹瞎猜，显然没看我贴得几个选项的描述，所以认为这就是 git 设计出来能很容易支持的东西。
其实这个需求 git 支持是很麻烦的，而且有很多问题的，包括可靠性和性能。
根本就不是所谓 git 基础的能力，既高级，又需要谨慎使用，又有很多限制。

@xiangyuecn
如果不是看到最后你觉得什么是对的，我一开始也不知道你到底要什么
这反映了一个事实，你自己也不会描述你得需求。不管是对于使用 git 工具还是使用 AI 工具，清楚自己的需求知道工具的能力和限制，才能达到目的。
是的，我就是来批判你的。你就是想不劳而获，也不想靠自己来知道工具如何工作，希望大家告诉你，然后能用就行了。
这整篇帖子的交流，就是一个探寻用户真正需求的过程，你就是那个 xx 用户。

相比于 --follow 你还可以用 --follow --follow ，甚至是显式地使用 --find-copies 甚至是 --find-copies-harder ，此时你可能还需要考虑使用 -l 和 --combined-all-paths 等等

显然你自己不会去翻文档的，也不会理解 git 如何工作，对吗

DataGrip 不用付费吗。。。可惜要

Navicat vim 模式都没有，直接劝退
试了几个不同的客户端，dbgate, DBeaver ，各有各的问题。各种小而美客户端根本不敢用，就怕有 bug

继续使用 GoLand 自带的，单买 DataGrip 倒是还不至于

你们说的是 Windows 版本吗？
还以为 Linux 版本单独的文件夹名呢，原来是 v4 开始全统一了

再加上 zygisk 换成 zygisk next 过北京燃气
唯一过不了的是微信和云闪付的指纹，因为解锁

直接用带上传功能的 HTTP server 就好，比如 HTTP FS

```
// nodejs Buffer
> Buffer.from([1]).toJSON()
{ type: 'Buffer', data: [ 1 ] }
```
特定类型的对象 json 序列化结果本来就依赖于类型，默认行为只会考虑本平台的反序列化。
要想跨平台识别，必须自定义序列化结果。
json 本身只是信息携带标准格式，没什么非法不非法一说。

倾向于用一组特别命名的私有方法去处理副作用，甚至单独封装成一个内部类，把状态对象的修改都放到里面，visitor 像调用纯函数一样调用这组方法。

在 windows 下只在睡眠模式下成功过，休眠模式失败，雷蛇笔记本。
linux 没试过 wifi ，只试过 lan 。
这个也分电脑。

你要想充分利用 git merge 的自动冲突解决能力，就不要做 squash 、fixup 、amend 、cherry-pick 这类会修改 commit 的操作，你必须在 merge 时原样保留各路 branch 。
你只要记住，如果你要 merge branch ，一定要保留 branch 原来的样子。因为 git 就是利用 branch 和 merge commit 来决定冲突解决结果的。

@netabare 我这样整体地描述该模式，看看是否命中了你的疑惑，因为我觉得可能你对这个模式的运转方式理解错了。

首先有一组固定类型的 object ，每个 object 内有多种类型的 element ，然后有多个 visitor 可以处理这组 object 。
每个 visitor 定义了一种将这组 object 输出为一种形式的业务逻辑，那么多个 visitor 分别代表可以输出不同形式的业务逻辑，visitor 之间是互相独立的。每种 element 需要对应一个 visitor 的 visitXXXElement 方法的实现。该方法的调用通过 element.accept 来做 dispatch ，这样就避免了业务侧用 switch case 做模式匹配，仅需 iterate elements 的 accept 方法即可完成调用。
其中关于 accept 的返回值，如果对这组 object 进行 visit 的结果是顺序的列表，自然可以直接将返回值简单地 map 为顺序列表。但如果 visit 的结果是其他复杂的类型，这部分业务逻辑必须由 visitor 在内部暂留状态，在整体 visit 结束后通过注入 end 的方法返回。这完全取决于要处理的业务，这部分不是该模式的核心。
其中关于 iterate elements ，这部分甚至也可以做到 visitor 的基类中，取决于 elements 的顺序如何产生，是统一的还是无关的。这部分不是该模式的核心。

举个例子，把一种 tree 输出为 json 、xml 、table 不同格式的业务。这里 tree 就是 object ，各种 tree node 就是 element ，json xml table 各需要一种 visitor. 其中对于 xml 如果选择用 element 嵌套的格式来表示输出形式，那么自然不可能直接由 accept 返回，因为整体结果是个 xml root element.

再补充一些各类现实情况：
- 什么情况下不能用开关控制：各定制功能客户要求不能将自己分支的源代码或功能泄漏给第三方。
- 什么情况下不适合用开关控制：定制功能基本没有共性，但代码同时存在，存在被互相引用的风险（当然这个可以用 lint 或 review 来控制）
- 多个定制方都需要相同的功能：1. 尽量从一开始设计好 2. 开发时，应从 base 分支创建分支，然后将该分支合并到各定制业务分支上
- 什么情况下不要用分支管理，而是分 repo：业务的技术实现会完全分叉，不管是基础库，还是业务框架，都会变得迥异，那么就没必要使用分支来确保同一个 base 代码了

我想说，大概就是因为你搞错了翻译，使得你理解错了这个模式。
visitor 不是观察者，visitor 是访问者。
visitor 模式用来解决的业务问题是——将访问图等各类对象数据结构的算法和其具体的业务逻辑分离，这里面 visitor 指的是 visit objects 。

至于该模式的具体实现，是否 accept 有返回值，不是首要重点，但也很重要，符合了最广泛的一种业务模式。
像 https://refactoring.guru/design-patterns/visitor 中的实现，无返回值。试想，如果 client 调用各类 ele 的 accept 返回各种 node 的处理结果，那么这些结果就需要由 client 自己集合为最终结果，但这部分是具体业务逻辑，应该由具体的 visitor 实现来负责。

对于 git 来说，你这两种模式没区别，都是 branch.
你说 fork 的时候是不是指 github 上的 repo 。这时候这两者的区别在于 repo 层面的管理，包括 org 、member 、permission 什么的。

你这种需求——拆出去、合回来，用 branch 管理是最合适的，设计好各种条件下如何建分支就好了。不要用什么 cherry-pick 甚至多项目。

大概是运行时生成的代码吧

能流畅使用基本的编辑功能就够了。
其他 IDE 能覆盖的也不需要费劲折腾 vim

可以从日常开发找痛点和提效出发