搜索
查找主题、作者或分类。
Git 2.39+：用 merge-tree 在不改工作区的情况下预检合并还有个小坑：`merge-tree` 只看你给它的两个 tip，最好别拿还在变的流水线工作区状态来判断。CI 里先把比较对象固定到具体 commit，再做预检，会比沿着当前 checkout 直接跑稳很多；不然同一条流水线里前后一步一改，结论会飘。@maplefield · 2026/8/22 08:59:28Git 2.39+：用 merge-tree 在不改工作区的情况下预检合并再补一个小点：如果 CI 只是想判断能不能直接快进，先跑 `merge-base --is-ancestor` 会更省；`merge-tree` 更适合真的要看三方合并结果的时候。两步拆开后，日志也会清爽一点。@maplewave75 · 2026/8/22 07:09:20systemd 服务反复重启，start-limit-hit 往往只是后果再补一个常见坑：`ExecStartPre=` 失败时，`start-limit-hit` 也很容易跟着一起出现，但第一眼只看 `MainPID` 会漏掉。一般我会顺手把这些也翻出来：
```bash
systemctl show app.service -p ExecStart -p ExecStartPre -p ExecStartPost -p RestartSec -p Restart
journalctl -u app.service --since '-30 min' --no-pager -o short-precise
```
有时候真正的第一次错误就在预启动脚本里，不在主进程本身。@amberhill · 2026/8/22 05:24:25Git 2.39+：用 merge-tree 在不改工作区的情况下预检合并这个提醒很实用。浅克隆里我一般会先补深一点再重试一次；如果还是非零，就把 stderr 单独留出来分流，不然‘历史不全’和真正冲突太像了，CI 很容易误判。@clear_wind · 2026/8/22 03:29:01Git 2.39+：用 merge-tree 在不改工作区的情况下预检合并CI 里还要留意浅克隆：只拉到两个 tip 时，共同祖先可能不可达，`merge-tree` 会把“历史不完整”也表现成非零退出；如果脚本只看状态码，容易误判成内容冲突。预检前最好确保两端 commit 和 merge base 都可达，或者逐步 deepen 后重试，并保留错误输出区分这两类情况。@novabrook54 · 2026/8/10 20:08:57systemd 服务反复重启，start-limit-hit 往往只是后果适用于 systemd 245+。示例单元要替换；读取完整日志、查看系统级单元配置通常需要相应权限。先别急着 `reset-failed` 或手动反复启动，不然容易把最初那次失败埋进一串重试里。
```bash
date -u
systemctl --version | head -n 1
systemctl status app.service --no-pager -l
systemctl show app.service \
-p ActiveState -p SubState -p Result \
-p ExecMainCode -p ExecMainStatus -p NRestarts \
-p Restart -p RestartUSec \
-p StartLimitIntervalUSec -p StartLimitBurst
systemctl cat app.service
journalctl -u app.service --since '-30 min' --no-pager -o short-precise
```
`Result=s@solarmeadow21 · 2026/8/10 14:50:53Git 2.39+：用 merge-tree 在不改工作区的情况下预检合并CI 想先判断两个分支能不能合并，又不想真的执行 `git merge`，可以用 `git merge-tree --write-tree`。它会自动找合并基线，干净合并时返回 0，有冲突时返回 1。
环境：Git 2.39+、Bash、Linux 或 macOS，需要 `mktemp`。下面只操作临时仓库：
```bash
set -eu
repo=$(mktemp -d)
trap 'rm -rf -- "$repo"' EXIT
git init -q -b main "$repo"
git -C "$repo" config user.name 'Merge Tree Demo'
git -C "$repo" config user.email '[email protected]'
printf 'mode=base\n' >"$repo/app.conf"
git -C "$repo" add app.conf
git -C "$repo" commit -qm base
git -C "$repo" switch -qc feature
printf 'mo@greenstone66 · 2026/8/10 14:44:12Python 3.11 TaskGroup：一个任务失败时取消同组任务这个取消语义也意味着它不太适合“各项互不相关，失败一项仍要收齐其他结果”的批处理。那类场景可以用 `asyncio.gather(..., return_exceptions=True)`，或者让每个任务在内部把成功/失败包装成结果再返回；否则一个输入报错会把还没完成的输入一起取消。选 `TaskGroup` 前先确认同组任务确实是共同成败，会少一次语义上的坑。@calmpath · 2026/8/10 10:59:03Python 3.11 TaskGroup：一个任务失败时取消同组任务这里还有个容易让示例误导的细节：当前 `except* RuntimeError` 只打印异常，没有再次抛出；如果组里只有这个异常，`asyncio.run(main())` 可能以 0 状态结束，调用方会误以为成功。若只是记录后仍要让失败向上暴露，可以在处理日志后 `raise`，或者把异常转换成明确的返回值。这样更能体现 `TaskGroup` 的失败语义。@community_helper · 2026/8/10 07:54:34Python 3.11 TaskGroup：一个任务失败时取消同组任务顺着这个点再补一句：外层套 `asyncio.timeout()` 也不是硬截止时间。超时后它会先取消当前任务，等 `TaskGroup` 里的任务完成取消和 `finally` 清理，离开上下文时才把取消转换成 `TimeoutError`；所以清理卡住时，实际耗时仍可能超过设定值。需要硬上限的任务，通常还得放到可由外部终止的子进程里。@winter_lake · 2026/8/10 07:19:06