gitingest 如何用 --include-submodules 把 Git 子模块纳入 digest【免费下载链接】gitingestReplace hub with ingest in any GitHub URL to get a prompt-friendly extract of a codebase项目地址: https://gitcode.com/GitHub_Trending/gi/gitingest如果你的仓库用 Git 子模块管理依赖代码用 gitingest 对它生成 digest 时会遇到一个问题默认的 digest 只包含主仓库的文件子模块目录下的内容不会进来。gitingest 提供--include-submodulesCLI和include_submodulesTruePython API来改变这个默认行为把子模块递归地克隆并写进 digest。本文说明安装、执行和验证这条操作路径。前提与默认行为环境要求Python 3.8见 README.md 的 Requirements 一节。安装 gitingest二选一pip install gitingest或使用 pipx首次使用 pipx 先运行pipx ensurepathpipx install gitingest子模块相关的关键默认值CLI 的--include-submodules是一个is_flagTrue, defaultFalse的开关见 src/gitingest/main.pyCloneConfig中的include_submodules同样默认False见 src/gitingest/schemas/cloning.py。也就是说不加该选项时子模块不会被克隆、不会进入 digest。这个选项作用于远程仓库克隆路径gitingest 克隆仓库并 checkout 到目标 commit 后才执行子模块更新见 src/gitingest/clone.py。对本地目录作为 source 的场景没有克隆过程也就没有子模块更新。CLI 执行步骤用仓库 URL 作为 source加上--include-submodulesusername/repo-with-submodules换成你实际的仓库gitingest https://github.com/username/repo-with-submodules --include-submodules输出默认写入当前工作目录的digest.txt。也可以用--output/-o filename指定文件名用--output/-o -直接输出到 STDOUT方便管道给其他工具。私有仓库需要在命令中携带凭据二选一见 README.md 的 Command line usagegitingest https://github.com/username/private-repo --token github_pat_... --include-submodulesexport GITHUB_TOKENgithub_pat_... gitingest https://github.com/username/private-repo --include-submodules注意子模块本身的远端仓库也需要可访问token 会随克隆流程传给 Git 操作。结果验证命令成功时的判断依据均为 src/gitingest/main.py 中实际输出的文本写文件模式终端打印Analysis complete! Output written to: digest.txt随后打印\nSummary:和 summary 内容。stdout 模式-o -在 STDERR 打印--- Summary ---…--- End Summary ---和Analysis complete! Output sent to stdout.。进一步核对 digest 内容打开digest.txt检查文件树部分是否出现了子模块目录及其下的文件。README 说明 summary 包含文件与目录结构、extract 大小和 token 数等统计若 digest 里看不到子模块路径说明子模块没有被纳入例如该目录只是普通目录而非.gitmodules中声明的子模块。克隆阶段内部的日志也会给出信号[src/gitingest/clone.py](https://link.gitcode.com/i/da34f52cfaccbfdb862c8dcaf74d2915)中只有include_submodules为真才会打印Updating submodules成功后记录Submodules updated successfully。Git 操作失败时抛出RuntimeError: Git operation failed: {exc}CLI 会以Error: ...形式报出并以非零状态退出。可选Python API 方式在代码里调用时参数名是include_submodules见 README.md 的 Python package usage 和 src/gitingest/entrypoint.py 的签名from gitingest import ingest # Include repository submodules summary, tree, content ingest( https://github.com/username/repo-with-submodules, include_submodulesTrue, )私有仓库可以传tokengithub_pat_...或预先设置环境变量GITHUB_TOKEN。与 CLI 不同ingest默认不写文件结果直接以summary, tree, content三元组返回需要落盘时传output参数-表示 stdout。Jupyter 场景下ingest_async可以直接await。内部机制与限制执行顺序基于 src/gitingest/clone.py校验仓库存在 → 解析目标 commit → 以--single-branch --no-checkout --depth1浅克隆 → checkout 目标 commit → 若开启子模块执行git submodule update --init --recursive --depth1。子模块更新是递归的--recursive且同样为深度 1 浅更新tests/test_clone.py 用断言submodule.assert_called_with(update, --init, --recursive, --depth1)固定了这一行为。整个克隆操作受DEFAULT_TIMEOUT超时包裹超时或克隆失败会抛RuntimeError: Git clone failed: ...。该选项自 v0.2.02025-07-26起提供见 CHANGELOG.md 中 Features:include_submodulesoption 条目。默认跳过.gitignore匹配的文件这一行为与子模块无关但若子模块内的文件被 ignore 规则命中需要另行加--include-gitignoredCLI或include_gitignoredTrueAPI。【免费下载链接】gitingestReplace hub with ingest in any GitHub URL to get a prompt-friendly extract of a codebase项目地址: https://gitcode.com/GitHub_Trending/gi/gitingest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考