@chutsetien 哦 我的错，我看到这里有个链接，不知道注册后能不能下载
https://info.microsoft.com/ww-landing-windows-10-enterprise.html?lcid=zh-CN

这里也有人提供了镜像，看起来是未作修改的
https://www.bilibili.com/read/cv14059705/

因为貌似好像没有这玩意儿，只到 2019
https://learn.microsoft.com/en-us/lifecycle/products/?terms=ltsc&products=windows
https://learn.microsoft.com/en-us/windows/release-health/status-windows-10-1809-and-windows-server-2019

importlib.reload() 可以动态更新模块

但是依赖于被更新模块的模块不会自动被更新，挺麻烦，可以试试 ipython 的%autoreload ，但还是有坑（ from module import something ），没研究过是怎么实现的

这个需求挺奇怪的，为什么不用多进程或者重启进程，大不了 subprocess 跑一个 python 脚本

火狐浏览器密码管理器

@zhwguest 帖子里是说了解决方案的
```
If it is the mouse, network card, usb port or other device, follow these steps.
Right click on Windows start menu and select "Device Manager"
In the new window, double-click the guilty device.
Then click the Power Management tab and untick the box next to "Allow this device to wake up the computer".
```
关于 away mode ，可以通过下面的教程关闭
https://kompy.info/away-mode-in-windows.html?page=13
关于 modern standby 的解决方案：
https://www.linkedin.com/pulse/understanding-configuring-modern-standby-improved-device-palmer

可以按照这个排查一下
https://answers.microsoft.com/en-us/windows/forum/all/my-computer-wakes-itself-up-from-sleep-mode/0c7209b0-5588-4cc1-acfa-54700429f3fc

我以前遇到过类似的问题，当时是 away mode enabled 导致的睡了就醒，现在可能是那个所谓的 S3 引起的，经常让我的本子在背包里发烫

已经有了，高铁上有那个 APP 的广告，忘了叫啥了，目标客户应该是老板或者想送人茶叶的

@mxT52CRuqR6o5 一个 git 的仓库，不管是裸仓库还是普通仓库，PATH 不包含你说的那些 blob pack 等等等等文件么？

@c3de3f21 不是打起来了，对任意技术一个问题，知道答案就回答，不知道就说不知道，不瞎猜，问题有误有不充分的就提出疑问，说一句“XXX 的原理没了解过么”，让别人猜谜语去吧，你看吵了半天，OP 的问题答案，还是不知道具体原因，在 OP 出来给出自己的配置之前，谁也答不上来真实具体的原因

@mxT52CRuqR6o5
path 为什么是打散的，目录是 path ，文件也是 path ，用 path 存就是直接简单直观的，甚至直接加一个 bucket://prefix 就可以同步到任何一个文件存储系统,加一个本地路径前缀就是本地文件系统，你自己电脑上 git 仓库不就是存在一个 path 么

@mxT52CRuqR6o5
首先："但凡 git server 基于 blob 、pack 去进行存储", 你这已经是在假设 git 服务的实现了
其次：我为什么不能直接使用 path 进行存储，非得用 blob ，pack 存储，将仓库所在 path 里的所有文件都存储在一个去重的文件系统/第三方存储服务里，不就实现了这个功能了么，并且抽象层次更好，不用记录 blob 、pack 和仓库的关系，直接目录作为仓库，和原生的 git 概念完全一致
最后：我这里不是在讨论什么样的服务设计更好，而是证明，问题讨论到这个范畴，已经不是 git 的问题了，而是 git 服务怎样实现才导致了这个情况，git 本身是保证不了复制（ fork ）一个仓库不增加存储空间的

@mxT52CRuqR6o5 我理解 OP 的问题和你的每一条回复，但你没明白我的观点：导致这个现象的原因根本不是 git 的底层实现，而是 git 服务（ gitlab GitHub or 自建的其他任何一种 git 托管服务）的服务实现，你所说的 edge case ，gc 等不重要更加应证了这一点：这不是 git 管的事情，不是 git 的底层原理，这是服务的事

@cc666 而我们没法假定 OP 的服务用的是什么，在 OP 给出更多信息之前，也不知道问题的答案

@mxT52CRuqR6o5 即使不是 blob 和 pack 存，是用小猫小狗存，只要他要在磁盘上存东西，结果都是一样，所以这个问题的本质和 git 的原理没什么关系，而是服务器的实现

@mxT52CRuqR6o5 不管是 blob 还是 pack ，还是小猫小狗存，结果都是一样的，答案就是：服务器存小猫小狗就行了
并且为什么假定服务器在复制一个仓库之后不对仓库进行 gc 呢，存 blob 和 pack 如果遇到 hash 冲突呢（ git 的 hash 冲突是存在的并且很坑的），这都是很复杂的情况，这其实和 git 的实现没什么关系，这完全是 git 服务的实现有关

@mxT52CRuqR6o5
“基于此原理就能实现一个 fork 不增加存储占用的 git 服务”
你这个回答就是假设了 OP 用的是一个能能够做到重复文件不增加存储空间的 git 托管实现或者服务器了

@mxT52CRuqR6o5 你 fork 的仓库和别人的仓库放在 path 么？ git 规定了么？ gitlab （假设是 gitlab ）用的不是复制而是软硬链接么？还是用的去重文件系统？

@mxT52CRuqR6o5 你干脆从因为这样所以这样来回答所有问题好了