注入 GIT "提交" 环境变量。

您的功能请求是否与问题有关?
是的: 正如运行 devpod 的机器上有效的凭据被注入到工作空间中一样,用于标识进行代码更改并影响最终提交的开发者的环境变量也应当被注入;如果没有此功能,提交很可能会错误地标识作者;手动为每个工作空间注入相关的环境变量既繁琐又容易出错。
您建议哪种解决方案?
Git 文档 规定:

Git commit 对象的最终创建通常由 git-commit-tree 完成,它使用这些环境变量作为其主要信息源,如果这些变量不存在,则会回退到配置值。
其中列出了影响提交的环境变量:

• GIT_AUTHOR_NAME
• GIT_AUTHOR_EMAIL
• GIT_AUTHOR_DATE
• GIT_COMMITTER_NAME
• GIT_COMMITTER_EMAIL
• GIT_COMMITTER_DATE
  我认为将这些列表中具有在运行 devpod 的机器上设置值的所有变量注入到工作空间中是有意义的。
  此功能不会违反 devpod 的无意见态:它已经对所使用的版本控制系统表达了意见,而且这是完全正确的: GIT 赢了 ;)

将与提交相关的 GIT 环境变量注入到工作空间中,就像注入其他类型的注入和转发一样,应该由 devpod 上下文 中的一个选项控制。
(顺便说一句,虽然文档中提到了 devpod 上下文功能(https://devpod.sh/docs/developing-in-workspaces/dotfiles-in-a-workspace#for-all-workspaces),但它目前还没有很好地记录下来;)
是否还应该通过 provider 中的一个选项来控制此注入取决于此领域的总体设计方法,目前我对此还不清楚:对于控制各种注入和转发的五个 上下文 选项,至少对于 gcloud 提供程序,只有两个在 provider 层面上具有类似选项,而且这些选项的名称与 上下文 选项不同:

• GPG_AGENT_FORWARDING
• SSH_ADD_PRIVATE_KEYS
• SSH_AGENT_FORWARDING
• SSH_INJECT_DOCKER_CREDENTIALS
• SSH_INJECT_GIT_CREDENTIALS 一个使此领域保持一致的方法是将用于控制转发和注入的所有选项都提供在上下文和所有提供程序中;另一种(我更喜欢的)方法是从所有提供程序中删除所有此类现有选项:我认为是否转发/注入并不特定于提供程序,而只属于 上下文 的粒度级别...
  (顺便说一句,我不确定由 SSH_INJECT_GIT_CREDENTIALS 上下文选项控制的注入是否特定于 SSH;如果不是, INJECT_GIT_CREDENTIALS 是一个更合适的名称;)
  (顺便说一句,还不清楚为什么,与所有其他注入/转发控制选项不同, INJECT_DOCKER_CREDENTIALS 和 INJECT_GIT_CREDENTIALS 在 gcloud 提供程序中没有类似选项,甚至这些选项的名称也不同:我认为是否转发/注入并不特定于提供程序,而只属于 上下文 的粒度级别...