Am 13.12.20 um 02:05 schrieb brian m. carlson: > Many people, through the course of their lives, will change either a > name or an email address. For this reason, we have the mailmap, to map > from a user's former name or email address to their current, canonical > forms. Normally, this works well as it is. > > However, sometimes people change a name or an email address and wish to > wholly disassociate themselves from that former name or email address. > For example, a person may have left a company which engaged in a deeply > unethical act with which the person does not want to be associated, or > they may have changed their name to disassociate themselves from an > abusive family or partner. In such a case, using the former name or > address in any way may be undesirable and the person may wish to replace > it as completely as possible. > > For projects which wish to support this, introduce hashed forms into the > mailmap. These forms, which start with "@sha256:" followed by a SHA-256 > hash of the entry, can be used in place of the form used in the commit > field. This form is intentionally designed to be unlikely to conflict > with legitimate use cases. For example, this is not a valid email > address according to RFC 5322. In the unlikely event that a user has > put such a form into the actual commit as their name, we will accept it. > > While the form of the data is designed to accept multiple hash > algorithms, we intentionally do not support SHA-1. There is little > reason to support such a weak algorithm in new use cases and no > backwards compatibility to consider. Moreover, SHA-256 is faster than > the SHA1DC implementation we use, so this not only improves performance, > but simplifies the current implementation somewhat as well. > > Note that it is, of course, possible to perform a lookup on all commit > objects to determine the actual entry which matches the hashed form of > the data. However, a project for which this feature is valuable may > simply insert entries for many contributors in order to make discovery > of "interesting" entries significantly less convenient. > > Signed-off-by: brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> > --- ... > diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh > index 586c3a86b1..794133ba5d 100755 > --- a/t/t4203-mailmap.sh > +++ b/t/t4203-mailmap.sh > @@ -62,6 +62,41 @@ test_expect_success 'check-mailmap --stdin arguments' ' > test_cmp expect actual > ' > > +test_expect_success 'hashed mailmap' ' > + test_config mailmap.file ./hashed && > + hashed_author_name="@sha256:$(printf "$GIT_AUTHOR_NAME" | test-tool sha256)" && > + hashed_author_email="@sha256:$(printf "$GIT_AUTHOR_EMAIL" | test-tool sha256)" && > + cat >expect <<-EOF && > + $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> > + EOF ... > + cat >hashed <<-EOF && > + $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> <$hashed_author_email> > + EOF > + git check-mailmap "$GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL>" >actual && > + test_cmp expect actual I don't understand the concept. A mailmap entry of the form A <a@b> <x@y> tells that the former address <x@y>, which is recorded in old project history, should be replaced by A <a@b> when a commit is displayed. I am assuming that the idea is that old <x@y> should be the "banned" address. How does a hashed entry help when the hashed value appears at the right side of a mailmap entry and that literal string never appears anywhere in the history? -- Hannes
