On 2024-03-17 00:16:26 +0100, Vivien Kraus wrote:
> Hello!
>
> Le samedi 16 mars 2024 à 17:50 +0000, Christopher Baines a écrit :
> > This is probably worth thinking about as Guix is in a similar
> > situation
> > regarding publishing source code, and people potentially wanting to
> > change historical source code both in things Guix packages and Guix
> > itself.
>
> I see two problems:
>
> 1. providing packages;
> 2. developing Guix itself.
>
> I am sure that 1. is not a real problem, we could just ask the
> developer to release a new version incrementing the patch number,
> upgrade it on our side, and forget the old version. Garbage collection
> would ultimately get rid of the old tarballs.

How would that approach interact with `guix time-machine'?  If developer takes
the approach of the package mentioned here (rewrite the history), would that not
cause the previous version to be no longer buildable, since the commit would no
longer exist?

I am not sure what the developer would do for old tarballs in this situation.
Re-release them from the re-written history or just drop them?  Either would be
a problem.  Or would they not care about dead name in the tarballs?

Currently SWH protects against the first (git commit), not sure if there is any
protection against the second currently (does SWH injects tarballs as well?).

Either I am missing something, or this would actually be a problem for the
time-machine use case.

> 2. is more difficult, because Guix contributors sometimes change their
> names too, and a commit reading “update my name” is not the best
> solution. If I understand correctly, rewriting the history would be
> understood as a “downgrade attack”, contrary to the ftfy case where the
> developer could rewrite the history without such consequences. Is my
> understanding correct?

For my use case using .mailmap was enough, but that was not a dead name
situation.  However it is a solution that works today, and changes the name
visible in most git operations (afaict) without modifying the history.  So
something to consider.


Tomas

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.