时间戳

首页 > 解决方案 > Git: Is it valid (and presumably forward compatible) to use non-email strings in the user.email config?

git - Git: Is it valid (and presumably forward compatible) to use non-email strings in the user.email config?

问题描述

The following works:

$ git config --local user.email "icq: 1234"

$ git commit --allow-empty -m "test"
[master 6d21d58] test

$ git cat-file -p HEAD
tree 6ef19b41225c5369f1c104d45d8d85efa9b057b53b14b4b9b939dd74decc5321
parent 3ea7111c6fda5a46bf1ccfd9193d483facb29356d7d9c833c54ba95265c58c55
author John Doe <icq: 1234> 1614734711 +0100
committer John Doe <icq: 1234> 1614734711 +0100

test

My question is whether this is properly supported by git or whether this is undefined behaviour, and whether it's reasonable to assume that a commit generated with a user.email that is not a valid e-mail string is going to remain a valid git commit in future versions of git?

标签： git

解决方案

Git 在该领域非常宽松，user.email因为电子邮件地址的生成非常复杂，如果没有某种生成器，在 C 中实现真正的解析器将非常困难。因此，此语法目前已被接受，并且出于这个原因，将来可能会继续被接受。

然而，许多其他使用 Git 的工具和语言确实假定它是一个可交付的电子邮件地址。例如，如果您使用 GitHub，它会根据您的电子邮件地址将提交与您的帐户相关联，您需要通过向该地址发送邮件来验证该地址，因此这些值将不会被接受。

此外，空格也会带来问题，因为 Git.mailmap在很多情况下都使用空格来重写旧的或不正确的名称和电子邮件地址。Git 或解析该格式的各种工具可能不会优雅地接受这样的语法，因此最好不要这样做。虽然如果 Git 本身在解析带有空格的电子邮件地址时出现问题，可能会为 Git 发布补丁，但通常许多人的假设（尽管不正确）是电子邮件地址不包含空格。

因此，虽然 Git 接受了这一点，但我不会依赖它在大多数情况下继续稳健地工作。如果您可以将这种情况下的ICQ地址重写为电子邮件地址，那就更好了。

推荐阅读