How does this work out for Git repos and other things with encryption backed histories? If I run a software project and a developer wants an identifying section of a repo back-edited, do I have to edit and rebase the whole repo, and what does this do to the trust in a project that is based on a verifiable history?

Also, I can't help but notice that currently there is a hell of a lot of money being bet on immutable public ledgers.

> Also, I can't help but notice that currently there is a hell of a lot of money being bet on immutable public ledgers.

I've been pondering the same thing. You have to be extremely careful about building a new product on blockchain technology, because, depending on what you're building, you may be required to delete stuff from it in the future.

Why are you accepting PII into your software projects' source repository in the first place?

Source repositories in many (most?) companies include the full names of the employees who authored every particular commit. This is PII. GDPR refers to all personal information you're handling, not excluding information of your employees.

The simple logical answer to that is that it is clearly impossible to blacklist.

The more specific answer is:

git config --global user.name "Your Name Comes Here"

git config --global user.email you@yourdomain.example.com

Also, looking up, you can undo a rebase with reflog, so even editing commits with an interactive rebase may not be enough to purge a git repo of identifiable information that people have entered.

I presume email addresses are PII?

Yes they are.

How it works out? Badly.

But you generally cannot build a system that intentionally does not have a certain capability and then successfully claim that laws don‘t apply to you, because your beautiful system does not accomodate them.

If this is an opern source repo on GitHub/GitLab, I think you could argue that the developer "made the data public" in giving it to you in the first place. That's an exception to the requirement to delete data. The same goes for public ledgers.

The tricky situation is when someone puts personal data not about themselves, but about a third party into a public ledger...

Is 'making data public' a plausibly reasonable defense tho? It's sad that that's not obvious.

I've been reading through the text of the act, and while there is an exception allowing you to process data that has been made explicitly public by the person it relates to without asking them for permission, it seems to indicate that you still have to give them the ability to edit it later.