Inject GIT "committing" environment variables.

[dubinsky]

Is your feature request related to a problem?
Yes: just as credentials in force on the machine running devpod are injected to the workspaces, so should be the environment variables identifying the developer making code changes and affecting the resulting commits; without this functionality, commits are likely to (silently) misidentify the author; injecting the relevant environment variables manually for each workspace is tedious and error-prone.

Which solution do you suggest?
Git documentation states:

The final creation of a Git commit object is usually done by git-commit-tree, which uses these environment variables as its primary source of information, falling back to configuration values only if these aren’t present.

and lists the environment variables that affect the commits:

• GIT_AUTHOR_NAME
• GIT_AUTHOR_EMAIL
• GIT_AUTHOR_DATE
• GIT_COMMITTER_NAME
• GIT_COMMITTER_EMAIL
• GIT_COMMITTER_DATE

I think it makes sense to inject into workspaces all variables from this list that have their values set on the machine where devpod runs.

This functionality does not breach the un-opinionatedness of devpod: it is already opinionated about the source control system used - and rightfully so: GIT won ;)

Injecting GIT commit-related environment variables, like other kinds of injections and forwarding, should be controlled by an option on the devpod context.

(By the way, although devpod context functionality is mentioned in the documentation (https://devpod.sh/docs/developing-in-workspaces/dotfiles-in-a-workspace#for-all-workspaces), it is not well-documented yet ;))

Should this injection be controllable also by an option on the provider depends on the overall design approach in this area, which at this point is not clear to me: of the five context options that control various flavours of injection and forwarding

• GPG_AGENT_FORWARDING
• SSH_ADD_PRIVATE_KEYS
• SSH_AGENT_FORWARDING
• SSH_INJECT_DOCKER_CREDENTIALS
• SSH_INJECT_GIT_CREDENTIALS

only two have analogues on the provider level (at least for the gcloud provider), and even those are named differently from the context options:

• INJECT_DOCKER_CREDENTIALS
• INJECT_GIT_CREDENTIALS

One way to make this area consistent is to have all the options that control forwarding and injection available on both the context and all the providers; another (the one I prefer) is to remove all such existing options from all the providers: I think that the choice to forward/inject or not is not provider-specific and belongs solely on the granularity level of context...

(By the way, I am not sure that the injection controlled by the SSH_INJECT_GIT_CREDENTIALS context option is specific to SSH; if it is not, INJECT_GIT_CREDENTIALS is a more appropriate name ;))

(By the way, it is not clear why, unlike all the other injection/forwarding-controlling options, GPG_AGENT_FORWARDING option defaults to false.)

Which alternative solutions exist?
Absent this feature, settings for those variables will need to be replicated in the workspace manually, which is tedious and error-prone.

[pascalbreuninger]

Hey @dubinsky, thanks for the suggestions! Forwarding these environment variables if they are configured on the host machine makes sense, let's implement it 👍

[dubinsky]

... makes sense, let's implement it 👍

Thank you!!