V2EX › geelaw 的所有回复 › 第 6 页 / 共 189 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 2 3 4 5 6 7 8 9 10 11 ... 189

❮

❯

2025 年 7 月 3 日

回复了 zifeixu85 创建的主题 › 问与答 › 问问大家一般都怎么寻找可注册域名的？

建议挪到“分享创造”。

我的方法是：需要赋予域名的对象本来就有名字。

2025 年 6 月 13 日

回复了 williamjing 创建的主题 › 问与答 › 如何找到 10-15 年前初中、高中人教版各个学科的教材 PDF？

@geelaw #9 重新尝试发现可以列出目录结构，但是不能下载文件，最后一次已知的可下载时间是 2024-01-09 ，同时注意到上面写着 powered by alist ，不知道这个变化是 alist 引起的还是站主的选择。既然如此，推荐 GitHub 上存档的版本。

2025 年 6 月 13 日

回复了 williamjing 创建的主题 › 问与答 › 如何找到 10-15 年前初中、高中人教版各个学科的教材 PDF？

@elvis923 #7 感到困惑，因为我直接访问就可以看到，不需要登录。（ IP 是美国家用宽带或者美国的数据网络。）

@ala2008 #8 很有趣的推理。

2025 年 6 月 13 日

回复了 williamjing 创建的主题 › 问与答 › 如何找到 10-15 年前初中、高中人教版各个学科的教材 PDF？

https://xue.zhoujie218.top/%E5%B0%8F%E5%AD%A6%E5%88%9D%E4%B8%AD%E9%AB%98%E4%B8%AD%E5%85%A8%E5%A5%97%E7%94%B5%E5%AD%90%E6%95%99%E6%9D%90

2025 年 6 月 5 日

回复了 KIRAYOMATO 创建的主题 › 问与答 › 有没有办法允许剪切但是不允许删除？

远程电脑不知道另一台电脑对移走的数据会做什么，实际上跨磁盘移动就是复制并删除原本，因此远程电脑的不可能选择性允许或禁止移动、删除。此外，这不是安全问题，所以权限模型不会建模之，因此不能用权限解决。

SMB 哪个系统都可以有，但并不是所有系统都有标准化的回收站功能，而且远程删除的文件也不一定能很好判断该放入哪个用户的回收站，因此 SMB 不太可能支持把远程文件移动到回收站。

现成的解决方案有 OneDrive：本地删除导致云端移动到回收站；本地删除时若文件已经下载到本地，则本地回收站也有一份；每台电脑可以选择使不同的文件离线可用。

或者自己写一个 SMB 访问程序，且不提供删除的 UI 。

2025 年 5 月 29 日

回复了 Fdyo 创建的主题 › Windows › Windows 更新将支持应用更新

>解决 Windows 系统中应用程序与系统组件更新割裂的问题

似乎是不存在的问题，主流操作系统里系统软件和应用软件的更新，一直都是分开的。当然，可以说这是一种新的尝试，但把一切都归结于一种缺点，属于是无厘头的 marketing 手段了。

2025 年 5 月 28 日

回复了 qazwsxkevin 创建的主题 › Windows › Win11 的开始菜单上，有固定图标区域，自建的快捷方式如何弄上去？

有些 lnk/exe 无法固定，是因为 manifest 等原因，例如 rundll32.exe 的 manifest 要求自己不被固定到任务栏和“开始”，但 rundll32.exe 的快捷方式无此限制。

2025 年 5 月 28 日

回复了 qazwsxkevin 创建的主题 › Windows › Win11 的开始菜单上，有固定图标区域，自建的快捷方式如何弄上去？

@Hayashikawa #1 和快捷方式的位置无关，Windows 的使用没有那么复杂。

如果要固定 exe 文件（应用程序）或者 lnk 文件（快捷方式），打开此文件的上下文菜单（“右键”），然后点 Pin to Start 就可以了。对于快捷方式来说，我记得至少从 Windows 8 开始就是这样了。

不过我刚才试了一下，24H2 上必须从 explorer.exe 里打开上下文菜单 Pin to Start 才会生效，在其他进程里（例如 Notepad 的“打开”对话框）虽然也有 Pin to Start ，但点击不会有任何作用。应该是和 Pin to taskbar 有相同的检测，但是枚举菜单项的时候忘了在非 explorer.exe 里不显示。

2025 年 5 月 25 日

回复了 ljiaming19 创建的主题 › 程序员 › 快速傅里叶变换(FFT)在很多行业都是常用算法为什么 intel/amd 这些 cpu 厂商没有为这个算法开发专用指令集

AES-NI 只是把 AES 中的一部分做成了指令，作用一次 AES PRP 需要调用指令多次，每个指令的参数也是定长的。特别地，并不是一个指令就可以加密任意长的字节数组。

类似的思路运用到 FFT 上，首先需要找出 FFT 中反复用到的同类、定长参数的步骤，然后做成指令，一通分析之后可能会发现没有很好的除了加法、乘法、求余数之外的很好的抽象层。

2025 年 5 月 23 日

回复了 xiangyuecn 创建的主题 › git › 问个 Git 基操：怎么样复制一个文件，能保持历史记录？

我在 #86 的主要观点有两个：

1. 如果你希望用一个工具自动检查文件复制的情况，应该问“有什么工具能追踪 Git 历史中复制的文件”，而不是“Git 基操：怎么样复制一个文件，能保持历史记录”，因为后者的自然解读是“保持 Git 所认为的历史记录”，即 git blame 的结果。
2. 如果你希望确保 git blame 总是得到你希望的历史（这和其他第三方工具没有任何关系），那么单纯复制 + git add + git commit 是不行的。

2025 年 5 月 23 日

回复了 xiangyuecn 创建的主题 › git › 问个 Git 基操：怎么样复制一个文件，能保持历史记录？

@xiangyuecn #87 您似乎没有理解“TortoiseGit 不是 Git”这句话。

你可以自己试试，在 Git 2.42 上

git init
>a.txt echo 1
git add a.txt
git commit -m first
>>a.txt echo 2
git commit -am second
cp a.txt b.txt
git add b.txt
git commit -m copy
git blame b.txt

你会看到 b.txt 的每一行都是 copy 导致的，而不是 first, second 导致的。

现在，为什么 TortoiseGit 会显示 b.txt 来自 a.txt （按照你的说法是这样的，我自己不用 TortoiseGit 所以不知道）。答案是因为 TortoiseGit 会自己读取 Git 的 commit 对象并自己追踪文件，和 git blame 没有任何关系。

Git 不会认为 b.txt 和 a.txt 有相同的历史，至于 TortoiseGit 有自己的解读方式，那是 TortoiseGit 的事情。本质上来说，你自己写一个追踪复制的程序，等价于你用 TortoiseGit ，都和 Git 自带的 blame 解读没有任何关系。

2025 年 5 月 23 日

回复了 xiangyuecn 创建的主题 › git › 问个 Git 基操：怎么样复制一个文件，能保持历史记录？

@xiangyuecn #78 我不确定为什么你认为 TortoiseGit 能识别 = 这是一个 Git 的基本操作。TortoiseGit 并不是 Git 。如果你期待的是存在一个基于 Git 的工具可以识别，提问的时候应该说清楚，你的答案是 TortoiseGit 的基本操作，而非 Git 的基本操作。

使用 merge 反复重命名的方法可以确保 Git 本身可以识别，这一点在你需要远程查看 git blame 的时候十分重要——毕竟没法要求 GitHub 远程帮你运行 TortoiseGit 。

2025 年 5 月 23 日

回复了 xiangyuecn 创建的主题 › git › 问个 Git 基操：怎么样复制一个文件，能保持历史记录？

@dfkjgklfdjg #30 git mv 和删除文件再新建没有任何区别。你在 #38 也说了，Git 是猜的，但

>但是如果猜到了，那么提交历史里面是会有标注是 rename

这是错误的，commits 里不会标注为 rename ，只有计算 diff/blame 的时候 Git 才会去（根据 commits 的内容）识别重命名关系。

2025 年 5 月 23 日

回复了 xiangyuecn 创建的主题 › git › 问个 Git 基操：怎么样复制一个文件，能保持历史记录？

@xiangyuecn #37 git cp 很难成立，原因：git mv 和 git rm 都不产生 commit ，而是修改 index 等，因此基于一致性，git cp 也应该不产生 commit 而只是修改 index ；但是 git 数据库里面每个 commit 存的是状态，而不是“怎么来的”，因此要让 git blame 认识到一个文件是另一个的副本，要么 git blame 自动检测（见下一段），要么这个信息必须存在于 commits 的历史中，用多分支的做法就是把这个信息存放在历史中，这必然要创建多个 commits ，因此 git cp 不会这样做。

目前的实现里，如果一个 commit 的惟一变化是有一个新文件 B ，并且新文件 B 和某个已经存在的文件 A 内容一样，那么 Git 会认为新文件是“手工重新写出来的”，不会认为 B 来自于 A 。我觉得这样设计的原因是很多配置文件可能确实会是内容上一样的，但更可能是基于不同的原因分别写出来的，所以不宜合并历史。

git mv 也并不保证 git blame 会认为移动前后的文件有关联性，这种信息依然是 Git 通过对比两个 commits 算出来的。

2025 年 5 月 23 日

回复了 xiangyuecn 创建的主题 › git › 问个 Git 基操：怎么样复制一个文件，能保持历史记录？

@magggia #9
@mercury233 #10
@mangoDB #19
见 #22

@xubingok #17 这当然不是造假，考虑各种变种需求：文件拆分成两个，希望各自保留历史；两个文件合并，希望保留各自的历史。

@Trim21 #21 模糊识别重命名确实有这个问题，但是 Git 的原理保证：如果一个 commit 里面只发生不同内容文件的重命名（没有内容修改、没有多个同内容文件重命名），那么历史可以正确用 blame 追溯。（不满足此条件则会有模糊匹配的问题，所以我给文件改名的时候都是一个 commit 只做改名一件事的。）

2025 年 5 月 23 日

回复了 xiangyuecn 创建的主题 › git › 问个 Git 基操：怎么样复制一个文件，能保持历史记录？

https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904

基本原理是：

- blame 在 merge commit 处会追踪文件来自各个 parents 的部份。
- 让文件 a 和 b 来自 merge 的两个 parents 。
- 让文件 a 来自更早的 a 。
- 仍文件 b 来自更早的 a 。

我的做法和 Raymond Chen 不一样，假设当前在 branch "current":

1. 重命名当前文件

git checkout -b copy
git mv a _
git commit -m 'Prepare to copy file.'

2. 把当前文件在第一个分支上恢复为原来的名字

git checkout -b copy1
git mv _ a
git commit -m 'Restore name of file.'

3. 把当前文件在另一个分支上重命名为副本的名字

git checkout -b copy2 copy
git mv _ b
git commit -m 'Copy file.'

4. 合并两个修改

git checkout copy
git merge --no-ff -m 'Finish copying file.' copy1 copy2

5. 回归原分支

git checkout current
git merge --no-ff -m 'Copy `a` to `b`.' copy

6. 删除中间分支

git branch -d copy copy1 copy2

1 ... 2 3 4 5 6 7 8 9 10 11 ... 189

❮

❯