 在 Windows 上的完整使用指南:换行符转换、分页器、PowerShell 转义、WSL 与符号链接)
Jujutsu (jj) 在 Windows 上的完整使用指南换行符转换、分页器、PowerShell 转义、WSL 与符号链接【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jjJujutsujj是一款与 Git 兼容的版本控制系统其核心语义在所有平台上保持一致但 Windows 用户在使用时会遇到换行符EOL、分页器、PowerShell 转义、WSL 执行位以及符号链接等特有的注意事项。本文以官方 Windows 指南 为主体结合仓库源码如 lib/src/eol.rs、core/src/file_util.rs深入讲解这些坑点与对应的解决方案。读完本文你将能够正确配置working-copy.eol-conversion与 Git 的core.autocrlf并保持二者同步、在 PowerShell 中顺畅使用与分页器、规避 WSL 挂载盘符导致的可执行位污染以及在 Windows 上正确启用符号链接支持。换行符Line Endings转换jj在所有平台上行为一致但 Windows 上最常见的首个坑就是换行符。jj提供了一个与 Git 的core.autocrlf类似的配置项working-copy.eol-conversion但当前并不读取.gitattributes也不读取 Git 的core.autocrlf配置因此官方建议手动保持这两个配置同步。三种转换模式该配置项在 config 文档 中有完整说明取值如下[working-copy] # 不做任何 EOL 转换。类似于 core.autocrlf false eol-conversion none # 仅在做文件 check-in从本地文件系统写入后端存储时应用 CRLF - LF 转换 # 而在 check-out从后端存储检出到本地文件系统时不应用 LF - CRLF 转换。 # 类似于 core.autocrlf input eol-conversion input # 在 check-in 与 check-out 两个方向都做 EOL 转换 # 工作目录中使用 CRLF仓库中保存 LF。类似于 core.autocrlf true eol-conversion input-output从源码看这个枚举定义在 lib/src/eol.rsEolConversionMode使用 kebab-case 反序列化包含None、Input、InputOutput三个变体并通过try_from_settings()从working-copy.eol-conversion读取lib/src/eol.rs。它被 lib/src/local_working_copy.rs 中的TargetEolStrategy实际使用快照snapshot阶段只有Input/InputOutput会把文本统一转为 LFconvert_eol_for_snapshot检出update阶段只有InputOutput会把文本转为 CRLFconvert_eol_for_update具体逻辑见 lib/src/eol.rs。二进制文件检测启发式与 Git 不同无论配置如何jj都会通过启发式方法跳过对二进制文件的 EOL 转换但这个启发式与 Git 和 gitoxide 并不一致jj目前仅通过文件中是否包含\0NUL 字节来判断二进制。从源码 lib/src/eol.rs 可以看到is_binary()的实现细节遇到\0返回true判定为二进制遇到单独的\r后面不是\n也返回true该实现还带有一个8KB 的探测上限PROBE_LIMIT 8 10见 lib/src/eol.rs只探测文件前 8KB 内容来判断二进制并且在探测边界处做了 CRLF 被截断的特殊处理lib/src/eol.rs。仓库注释明确表示lib/src/eol.rsjj目前不打算与 Git 的二进制检测算法对齐Git 的算法见git的convert.c、gitoxide 的gix-filter/src/eol/utils.rs。这意味着jj可能对某个文件是否为二进制做出错误判断并错误地应用换行符转换。当前不支持针对单个文件配置 EOL 转换由于jj目前不支持对特定文件单独配置换行符转换行为如果你恰好命中了误判场景最稳妥的做法就是不要启用换行符转换配置同时关闭 Git 的core.autocrlf。这一点在官方文档中以醒目提示note的方式强调也是 Windows 用户最需要记住的兜底策略。与 Git 配置保持同步由于jj不读取 Git 的core.autocrlf在 colocated共置工作区中如果你忘记同步两个配置可能会得到只包含 EOL 差异的脏工作副本。此时可以先把working-copy.eol-conversion设置正确再运行jj abandon修复。禁用换行符转换的完整命令若要彻底禁用转换将core.autocrlf设置为none或直接删除该设置并在jj侧做如下操作官方给出的 PowerShell 示例PS git config core.autocrlf input # 我们使用 none 而不是 input以避免应用 EOL 转换 PS jj config set --repo working-copy.eol-conversion none # 放弃工作副本会让 Jujutsu 用提交时的行尾很可能是 LF覆盖所有文件的 CRLF 行尾 PS jj abandon注意jj config set --repo只作用于当前仓库配置会写入仓库级配置若想全局生效可改用--user。仓库默认配置中eol-conversion none、exec-bit-change auto的定义见 lib/src/config/misc.toml。设置完成后效果是行尾将按提交时的原样检出按编写时的原样提交exactly as committed / exactly as authored。同时要确保你使用的工具尤其是 IDE能够保留 LF 行尾因为 Git 一侧需要保证以 LF 检出而不再转换为 CRLF。分页器Pager默认使用内置 streampager在 Windows 上除非显式配置了ui.pagerjj默认使用其集成的分页器streampager。这一定义可以在平台默认配置 cli/src/config/windows.toml 中看到[ui] pager :builtin editor Notepad也就是说 Windows 默认的ui.pager就是内置分页器:builtin而其他平台默认走less -FRXK。分页相关的完整配置说明见 config 文档的分页器章节。如果你安装了 Git但想改用 Git 自带的less作为分页器例如内置分页器无法满足需求时官方给出的命令如下PS jj config set --user ui.pager [C:\\Program Files\\Git\\usr\\bin\\less.exe, -FRX] PS jj config set --user ui.paginate auto其中ui.paginate控制分页行为的开关可选值为[ui] # 对支持分页的命令启用分页默认 paginate auto # 完全禁用分页等价于 --no-pager paginate never内置分页器基于 streampager 实现但直接在jj的配置里调整相关配置位于ui.streampager表config 文档。常用按键包括按键动作Ctrl-c或q退出h或F1显示所有按键绑定Esc关闭帮助或提示\切换自动换行#切换行号显示Ctrl-r切换标尺ruler常用配置示例[ui.streampager] wrapping word # 按单词边界换行默认 anywhere interface quit-if-one-page # 短输出自动退出默认值 show-ruler false # 启动时不显示标尺默认 true需要注意JJ_PAGER环境变量可以覆盖ui.pager通用环境变量PAGER则会被忽略config 文档。在 PowerShell 中输入的转义问题PowerShell 将用作数组子表达式运算符array sub-expression operator的一部分因此在jj命令中直接写表示工作副本提交经常需要转义或用引号包裹PS jj log -r PS jj log -r 一种更优雅的解法是创建 revset 别名。例如让HEAD成为的别名PS jj config set --user revset-aliases.HEAD PS jj log -r HEAD这样日常命令中就不再需要处理的转义问题。WSL 下所有文件都被设置执行位的问题当你从 WSL 访问 Windows 盘符通过/mnt/c或类似路径时Windows 会把所有文件都暴露为带有执行位execute bit。由于jj会自动记录工作副本的变化这会导致仓库中提交的所有文件都被设置上执行位。从源码看这一问题的根源在于执行位的处理策略jj在 Unix 上通过向工作目录写入临时文件并尝试翻转用户执行位来探测文件系统是否支持执行位check_executable_bit_support见 core/src/file_util.rs而 NTFS 挂载盘不支持真实的执行位语义。jj的快照逻辑会据此把工作区状态记录进仓库。官方的解决方案分两种场景如果只在 WSL 中访问仓库最好把仓库克隆到 Linux 文件系统中例如~/my-repo彻底避开挂载盘符的问题。如果需要在 WSL 和 Windows 两边同时使用该仓库可以借助jj的多工作区workspace能力在 Linux 文件系统上创建一个工作区PS jj workspace add --name wsl ~/my-repo然后只从 Linux 使用~/my-repo这个工作区。jj workspace add的--name参数用于指定工作区名称默认取目标路径的 basename相关命令参数定义见 cli/src/commands/workspace/add.rs。注意在 Windows 上jj会保留树中已有的执行位状态见 lib/src/local_working_copy.rs 中关于 Windows 下保留执行位的注释因此在 Windows 侧改动文件、在 WSL 侧提交时执行位可能被意外记录这也是把 WSL 工作区放到 Linux 文件系统的原因。符号链接Symbolic Link支持jj只有在操作系统允许时才支持 Windows 上的符号链接具体前提是Windows 10 版本14972或更高已开启开发人员模式Developer Mode。如果条件不满足jj会把符号链接物化为普通文件materialize symlinks as ordinary files。源码实现印证了这一点Windows 平台下的check_symlink_support()会读取注册表键SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock中的AllowDevelopmentWithoutDevLicense值来判断开发人员模式是否开启见 core/src/file_util.rs若未开启创建符号链接会返回错误码 1314ERROR_PRIVILEGE_NOT_HELD。而 Unix 平台上符号链接始终可用core/src/file_util.rs。对于colocated 工作区与 Git 共置还需要在 Git 侧启用支持git config core.symlinkstrue从源码还可以看到一个跨平台细节Windows 下把符号链接目标写入仓库时jj会把\分隔符转换为/以便符号链接在 Unix 上仍然有效见 lib/src/local_working_copy.rs 中的symlink_target_convert_to_store/symlink_target_convert_to_disk这保证了 Windows 创建的链接目标在 Linux 检出时依然可用。总结与建议清单针对 Windows 用户整理一份可直接落地的操作清单换行符决定好行尾策略后让jj的working-copy.eol-conversion与 Git 的core.autocrlf保持一致若出现只有 EOL 差异的脏工作副本修正配置后运行jj abandon若jj误判二进制文件请直接禁用两个转换配置。分页器默认:builtinstreampager已可用需要时切换到 Git 自带less.exe并配合ui.paginate auto。PowerShell 的用反引号或单引号更推荐用revset-aliases定义别名一劳永逸。WSL仓库放在 Linux 文件系统~/my-repo双端共用时用jj workspace add --name wsl ~/my-repo创建独立工作区避免执行位被批量污染。符号链接Windows 10 14972 且开启开发人员模式colocated 工作区还需git config core.symlinkstrue否则链接会被物化为普通文件。相关配置的完整参考可继续阅读 config.mdEOL 转换见 eol-conversion 小节、分页器见 pager 小节多工作区机制见 working-copy.md 的 workspaces 小节换行符转换的底层实现与测试见 lib/src/eol.rs。【免费下载链接】jjA Git-compatible VCS that is both simple and powerful项目地址: https://gitcode.com/GitHub_Trending/jj/jj创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考