On 2024-08-15 at 15:24:47, shejialuo wrote: > If the user uses the following command: > > $ export GIT_DEFAULT_HASH_ENVIRONMENT=sha1 > $ git -c init.defaultObjectFormat=sha256 repo > > The repo would be initialized with the sha1 algorithm. I think we should > think carefully which precedence should be higher. I cannot give an > answer here. I am not familiar with the whole database and do not the > concern. But from my own perspective, I think the precedence of the > config should be higher than the environment variable. This is a new > feature, the people who would like to use it, they will never use > environment variable and we should ignore the functionality of the > environment variable. But for people who do not know this feature, they > will continue to use the environment variable and they will never be > influenced by the configs. The standard behaviour we have with other environment variables is that they override the config, such as with `GIT_SSH_COMMAND` and `GIT_SSH_VARIANT`. The reason is that the config in this case is usually per-user or per-system, but it's very common to override settings on an ephemeral basis with the environment. Think of the case where you have a language package manager that's creating a repository or fetching from one. You can override on the command line with `GIT_DEFAULT_HASH` or `GIT_SSH_VARIANT`, but you can't control the actual `git` invocation, since it's baked into the package manager. Or if you're writing a test and need all of the Git commands to use a particular setting, then it's easy to simply set the environment once and forget about it. (This is what we do at $DAYJOB to implement SHA-256 test modes for our repos: the test script sets `GIT_DEFAULT_HASH` and all of our test repos magically use the right setting.) -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
