From: MSavoritias <email@msavoritias.me>
To: Andreas Enge <andreas@enge.fr>,
Simon Tournier <zimon.toutoune@gmail.com>
Cc: Attila Lendvai <attila@lendvai.name>, Ian Eure <ian@retrospec.tv>,
guix-devel <guix-devel@gnu.org>
Subject: Re: rewriting history; Was: Concerns/questions around Software Heritage Archive
Date: Mon, 18 Mar 2024 16:03:20 +0200 [thread overview]
Message-ID: <eb4ee086-6e1a-9503-1090-c5b0fe2e7149@fannys.me> (raw)
In-Reply-To: <ZfhDHvP1B21jkjqB@jurong>
On 3/18/24 15:35, Andreas Enge wrote:
> Hello all,
>
> Am Mon, Mar 18, 2024 at 12:26:18PM +0100 schrieb Simon Tournier:
>> Therefore, it would be more constructive if you come with a
>> proof-of-concept allowing “history rewrite” and strong “software
>> identification” property
> the one thing I can think of, and which would allow time travel to coexist
> with history rewriting, is an additional layer of metainformation.
>
> First of all, when rewriting history, all commits from the bifurcation
> to an alternate universe must be signed again by the person doing the
> "time split"; so there is a loss of information there.
>
> Second, we need to create a table that associates every old, lost commit
> hash to the corresponding new commit hash; this should also be signed by
> the person rewriting history.
>
> Of course this will have to be continued to the future: If Guix has n
> commits and m history rewrites, then the m-th rewrite may have to create
> a table of n entries that link commit hashes of the m-th rewrite to those
> of the (m-1)-th rewrite. Total memory would become m*n entries.
>
> When doing time travel to a commit hash, one would need to check whether
> it is available in the current, m-th history rewrite; if not, one would
> need to look for it in the (m-1)-th rewrite and map it to a commit hash
> in the m-th rewrite; if not, one would have to look for it in the (m-2)-th
> rewrite and map it to a hash in the (m-1)-th rewrite, and then check
> whether or not it has been overwritten in the m-th rewrite. The total
> time complexity would be m look-ups in tables of size n each.
>
>
> It is a lot of effort; and probably for little gain, since we cannot
> eradicate each and every fork of the Guix git repo. The old data will
> still be available at SWH, and probably at random forks on lots of random
> forges all over the world. As Simon, I think that history, fundamentally,
> cannot be rewritten: What has happened in the past, has happened in the
> past. If you have done some public activity as the person known as X, and
> then change your name to Y, you cannot prevent your past activity to be
> known under identity X. Also, the time split would have to be publicly
> documented somehow; if we add as rationale for a history rewrite "person X
> is now known as Y", not much is gained compared to just keeping the old
> commits. Not documenting the rationales for history rewrites would not help
> to instill trust in the codebase, and probably not solve the problem either,
> since it is quite likely that the request by person X to now be addressed
> as Y will have been made on the mailing list or some other public forum.
>
> So my impression is that the .mailmap approach in the Guix project is a
> good compromise between acknowledging the wish of people to be known under
> identity Y, and what can reasonably be achieved to hide identity X.
>
> Well, there are things people can do individually:
> 1) Use a pseudonym P from the start instead of X (which is admitted in
> the Guix community, just look at a few of the names: there are pseudo-
> nyms with clearly made-up first and last names, there are very obvious
> one-word pseudonyms, and maybe some of the names that look like real
> names are not from the persons' passports, who would know).
> 2) This does not help, of course, if you are already known as X and want
> to be known as Y. Then either you can somehow make the change publicly,
> and transfer your reputation and also the information that you used
> to be known as X, or disappear as X and reappear as a new person Y
> and lose X's reputation. Doing both is impossible, I would say.
>
> Andreas
>
Rewriting history is the wrong question imo. I dont think a request to
change all of the history of Guix will be accepted anyway.
A much easier thing to do is to change the approach in the future. And
let all the past history untouched.
MSavoritias
next prev parent reply other threads:[~2024-03-18 14:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 0:10 rewriting history; Was: Concerns/questions around Software Heritage Archive Attila Lendvai
2024-03-18 10:10 ` MSavoritias
2024-03-18 11:26 ` Simon Tournier
2024-03-18 12:08 ` Daniel Littlewood
2024-03-18 21:14 ` Tomas Volf
2024-03-19 10:04 ` Attila Lendvai
2024-03-18 13:35 ` Andreas Enge
2024-03-18 14:03 ` MSavoritias [this message]
2024-03-18 14:19 ` Andreas Enge
2024-03-18 14:33 ` MSavoritias
2024-03-18 15:14 ` Andreas Enge
2024-03-18 15:34 ` MSavoritias
2024-03-22 22:48 ` indieterminacy
2024-03-18 10:51 ` pelzflorian (Florian Pelz)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eb4ee086-6e1a-9503-1090-c5b0fe2e7149@fannys.me \
--to=email@msavoritias.me \
--cc=andreas@enge.fr \
--cc=attila@lendvai.name \
--cc=guix-devel@gnu.org \
--cc=ian@retrospec.tv \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).