--grep 是查找 commit message 不是文件内容

不嫌慢可以用 for-each-ref 啊

用 worktree 就可以

仍然是不知所云，没有看论文本身，也许只是解释的文字不知所云

如果目的仅仅是分发一个 lite 版的代码, 那条件编译不是早就解决了，而且是真正意义的删除了代码

发快了, github 的链接居然掉了

https://stackoverflow.com/questions/872565/remove-sensitive-files-and-their-commits-from-git-history/32840254#32840254

理论上可以做到禁止
如果在你 force push 之前别人已经 fetch 过那当然无法禁止
其余情况下可以通过在服务器上执行 prune 删掉 dangling object (前提是你可以操作服务器), 或者最彻底的方法是删除 repo 然后重建

至于 github, 这里说的很详细

BTW, 印象中之前好像基于安全或其它原因一直是不允许 git fetch origin <SHA> 的, 但貌似新版的 git 服务器 (2.20.1?) 又允许了 https://stackoverflow.com/questions/14370157/git-fetch-a-specific-commit-by-hash/62463160#62463160

https://b23.tv/9Xb4RUj 为啥刚刷到的这里说的刚好相反的

仅仅是 rsa 为什么要用 x509 封装呢
https://www.npmjs.com/package/js-jsbn

四号线沿线北到万胜围琶洲车陂南到亚运村
七号线沿线南到员岗南村万博汉溪长隆

应该用 brew deps --tree `brew leaves` 更好一些

这就是撕番啊

槽多无口
真要和协程扯上对标的也应该是 bio 而不是 nio
nio 是提供事件驱动实现（协程也是其中之一）可能的底层之一

通过 JSDoc, 可以在目标地点写一个 [at] name 或 [at] typedef, 在引用点用 [at] type 或 [at] see

以前牙膏厂时代还有纠结的理由, 现在只要没有大屏的刚性需求, 无脑买 14 就对了, 同配置几乎没有性能差别, 只有续航的区别

1. tcp 默认没有这样的行为，但万恶的防火墙有，并且粗暴的不完成完整的 tcp 断开流程约定，会造成业务无响应
2. http 找你的服务器文档看如何配置
3. 自己实现 tcp 服务器的话需要自己去实现断开的逻辑
4. 建议取值略小于防火墙设置，这样的性能最优，而如果不希望保持太多的空闲连接，可以设置为一到两分钟空闲关闭

maven 的依赖 resolve 是协作式的, 同一个包 (groupId:artifactId) 只能导入一个版本, 具体 resolve 到的哪一个版本在编译时是确定的, 规则虽然不是特别的复杂, 但也不是一句话能说的清楚, 可以用工具帮助解决冲突

并且实际上, groupId:artifactId 和 package FQN 没有严格对应关系这使得问题会更加复杂一些, 同一个 package 可能会被不同的 artifact 导入了超过了, 那么这时候编译以及运行时使用的是哪一个 jar 就变的不确定了, 这样的情况要尽量避免出现

作为想对面, npm 采取的是完全相反的方式, 就是每个 package 及其依赖都是尽量内蕴的, 两个一级依赖之所以用到了同一个次级依赖, 只不过是因为这个二级依赖的版本号恰巧是相同 (npm 会在条件允许下让它们尽量恰巧相同)

表面看起来 npm 的依赖管理简单易懂, 但实际上却复杂的多的多, 并造成了一大堆遗留到现在都很无语的问题

@beryl 你还是没理解, 关键在于 review 权限和 merge 权限分开, 既然你不需要控制 merge 只希望控制 review, 而又懒的找个人去点按钮, 甚至可以写个 robot 在 reviewer 点 approve 的同时自动 merge

当然, 如果开发者完全不配合, 自己点 approve 按钮, 而又不想分配人员来行使复核并 merge 的责任, 那么你可以让 robot 只是简单的检查 approver 必须和 submitter 不同, 也就是说 submitter 必须找个人帮他点 approve 按钮

@beryl 我们用的是 13 ，好像并不是 ee 专有的功能

新版的支持 approve 啊，可以收回 merge 权限，分配 reviewer ，要求必须经过 approval 才允许 merge ，负责 merge 的人不需要负责 review