新增用于修剪不可达对象 (unreachable object) 的机制
新增适用于 Windows 和 macOS 的内置文件系统监视器
稀疏索引 (sparse index) 已可以广泛使用
修剪不可达对象
在 Git 中，对象可被分类为“可达”和“不可达”。当至少有一个引用（分支或标签）时，一个对象是“可达的”，你可以从该引用开始一个对象遍历（从提交遍历到其父级，从树遍历到其子树，等等），然后在目的地结束。类似地，当不存在这样的引用时，一个对象是“不可达”的。
Git 2.37 引入了一个新概念
cruft packs
，它允许将“不可达”对象一起存储在单个包文件中，方法是将各个对象的 age 写入存储在包旁边的
*.mtimes
文件的辅助表中。
在实践中，它们可以允许仓库以更长的宽限期来进行修剪，而不必担心创建许多松散对象的可能性。通过运行下方命令进行尝试：
$ git gc --cruft --prune=1.day.ago
内置文件系统监视器
工作目录大小是显著影响 Git 性能的其中一个因素，
例如，当你运行
git status
.git 时，Git 必须爬取你的整个工作目录（在最坏的情况下）才能确定哪些文件已被修改。
Git 对文件系统有自己的
cached understanding，
以避免在许多情况下进行整个目录遍历。但是对于 Git 来说，在工作时使用磁盘的实际状态更新对文件系统的
cached understanding
可能会很昂贵。
过去，Git 可以通过
hook
与 Watchman 等
工具集成，从而可以用更直接地跟踪文件系统状态的长时间运行的守护进程来替换 Git 昂贵的刷新过程。
但是设置这个钩子并安装第三方工具可能很麻烦。在 Git 2.37 中，此功能内置于 Windows 和 macOS 上的 Git 本身，无需安装外部工具和配置钩子。
通过启用
core.fsmonitor
配置设置即可为仓库启用此功能。
$
git config core.fsmonitor
true
完成配置后，初始
git status
命令将花费正常的时间。
详情查看发布公告
。
展开阅读全文
本站新闻禁止未经授权转载，违者依法追究相关法律责任。授权请联系：
oscbianji#oschina.cn
本文标题：
Git 2.37 正式发布，支持修剪不可达对象、稀疏索引可广泛使用
本文地址：
https://www.oschina.net/news/201109/git-2-37-released
Thread-local variables Virtual threads support thread-local variables (ThreadLocal) and inheritable thread-local variables (InheritableThreadLocal), just like platform threads, so they can run existing code that uses thread locals. However, because virtual threads can be very numerous, use thread locals only after careful consideration. In particular, do not use thread locals to pool costly resources among multiple tasks sharing the same thread in a thread pool. Virtual threads should never be pooled since each is intended to run only a single task over its lifetime. We have removed many uses of thread locals from the JDK's java.base module in preparation for virtual threads in order to reduce memory footprint when running with millions of threads. The system property jdk.traceVirtualThreadLocals can be used to trigger a stack trace when a virtual thread sets the value of any thread-local variable. This diagnostic output may assist with removing thread locals when migrating code to us
本人原创作者，在此解释声明一二： 1. 我的父母还没有无耻到做这种无耻的事情，我也对我的能力有信心，目前也不需要这些偷鸡摸狗的见不得光的东西来造假，请各位不要以小人之心度君子之腹。 2. 我今年初三，项目是从初一开始做的，各位不相信的欢迎上github看提交记录，可以看一下初版和现在的区别，UI和js都有不小更改。 3. 团队组成：今年一位初三，一位初一，一位5+4制的初一。更新记录中明确记录了哪些功能是哪位所开发的。 4. 我在github上，bilibili上没有受到过任何一个人的质疑，我对中国的网络环境表示蔑视。 5. 本项目的初中只是为了兴趣，没有想到火了起来。 我不理解你们是如何通过代码读出作者年龄的？难道是语文考试要加入代码阅读赏析的题目了吗？真心觉得很厉害。 6. 不愿与某些人同流，也无众位深厚阅历经验，只望能得清白之名。感谢大家让我懂得了何乃人情世故，孰谓世态炎凉，世俗红尘。你们给我的人生上了重要的一课。人间哪有什么真善美啊，呵。社会的病胎罢了。
看了 wangEditor 的公告，如鲠在喉。去年七月，我在一篇《关于剔除 layedit 组件》的公告中，还推荐了几款 editor 组件用于替代，其中就包括了 wangEditor, 转眼之间，仿若时空交错，不免有些感慨。 在国内由个人发起的开源项目，似乎都很难跳出相同的宿命，不断有人走进这个赛道，但能抵达终点并完成突破的却屈指可数。Layui 曾经同样倒在了赛道，2021 年宣布关站之前，Layui 的百度指数还一度领先 Bootstrap, 如此一个拥有广泛用户群体的 UI 库，本该迎来新的突破，却在疾跑中戛然止步，至今令人迷惑。人们看到的，是一篇充满悲情色彩的公告，而公告的背后，是创作者在面对内外交织的困境中不得已做出的举措，当我们没有足够的力量冲破眼前的障碍，除了停下来避开它，还有别的更优选择么。你很难想象除此之外还有多少历史包袱… 譬如，也是由于种种原因，当初 Layui 在 Github 和 Gitee 待处理的 Issue 数量，不下于 2000，各种议题参次不齐，我差不多花了半年时间去逐一审阅，多少个日夜消耗，多少次自我情绪的对抗… 就不多提了。 尽管这两年来，Layui 的受众者已呈断崖式流失，但正因为小众，反而如释重负，甚至让我重新找回了一些开源的纯粹。 共勉 🙂
专门登录写个评论，为了信创而信创没有任何意义。 如果开源的spring被认为是非自主可控不安全的，那请问Linux和Java属于自主可控吗？那些大数据和人工智能的组件属于自助可控吗？Docker和K8s属于自主可控吗？ 真要完全安全自主的话，国内的计算机行业应该从汇编开始发展。 师夷长技以制夷，我支持自主研发、自主可控的信创策略，但应该是更底层的芯片、操作系统、虚拟机、容器化这些基础组件的研发。像中间件、应用框架这些东西，就算一夜之间所有github的代码全部消失了，集合几家大厂的能力，开发出来又能花多少时间呢？况且现在大厂本身就有很多自研的中间件和框架。 本身东西就不复杂，现在spring、redis这些东西流行只是因为它们诞生的早生态好罢了，而不是难度。为此单独再搞一套轮子我觉得大可不必。
