Re: Idea: indirect authorship info

[Junio C Hamano <gitster@pobox.com>]

Yawar Amin <yawar.amin@gmail.com> writes:

> Apologies if this has been brought up before, but I failed to find anything
> relevant from some quick searches:
>
> - https://lore.kernel.org/git/?q=indirect+authors
> - https://lore.kernel.org/git/?q=authors+file
> - https://lore.kernel.org/git/?q=people+file

Try "mailmap+deadname".  You essentially reinvented these earlier
proposals, except that they reused the existing ".mailmap"
mechanism, and how the key is chosen.

While I do not think of any reason why the desire to achieve the end
goal of these efforts is bad, some parts of your design (and other
proposals) need rethinking.

Projects often need to know and show who did what for legal reasons.
Imagine an old commit needs to be shown to document who made the
contribution to the project.  An in-tree ".mailmap" file can give
adequate guarantee that the anatomized commit author name the commit
carries documents who it the really is in the ".mailmap" file
recorded in the tree of that partcular commit, even if some
contributors who stopped contributing and asked to go back to
anonymity have disappeared from that file.  But they may still
appear if you did "git log -p .mailmap", which would meet the needs
of these projects, but it means that you cannot be forgotten and
have to live with the consequences of what you did in the past.  On
the other hand, if there is no in-tree ".mailmap" (or "people")
file, it brings up many questions.  It becomes unclear who will keep
track of the latest version. There needs a way to guarantee that the
entries still in the mapping file can be used to verify the claim
that some person did a particular commit.  Of course, as long as it
is distributed to project participants for communication ("hey you
worked on this feature 6 months ago; can you answer a few
questions?") and verification ("yes, this commit was done by this
person who was not affiliated with company X in any way. how do you
substantiate your claim that this project stole it from the
company?")  purposes, somebody will bound to make and keep copies,
which means that you cannot become truly anonymous, after making
yourself known.

As to the choice of the anonymous key used as a stand-in value for
the author and the committer identity, using something that is not
deterministic (like uuid) is not a good idea.  If the name/address
are hashed with some algorithm that is cryptographically secure and
is one-way, it would probably suffice both for anonymity purposes
(as you need to "reverse" such a hash to get to the real author) and
allows easy verification (if you need to "prove" that an anonymised
author 9f5d8e44edfb7e1aa4dcf34acc3b4d643f83e1b6 recorded in the
commit object is an author with a known name/address, you can feed
that name/address to the hash function and if it hashes to the same
value, that claim is as good as having the name/address directly
recorded in the commit object.