Subject: Re: Git Privacy

From: "nick" <[email-masked]>
Date: Fri, 14 Jul 2023 09:22:44 +0000

> "nick" <[email-masked]> writes:
>
> > hooks. Perhaps a config option to automatically set the date to a time
> > before Git was invented?
>
> [...] I am not yet convinced that it is worth the engineering effort
> for this project to review, accept and maintain changes to implement
> it.

Upon further thought, given that it's already pretty easy to accomplish
timestamp obfuscation, albeit clumsy, I concede that it may not be worth
the engineering effort to implement my original suggestion. So I'll drop
it.

However, I think it is worth the effort for the time zones. Is there any
reason Git doesn't automatically convert local time to UTC in timestamps
to prevent leaking the developer's time zone?

It seems like a simple change that would be good for the developer's
privacy without harming Git in any way. It would also be easy to
implement as backwards-compatible.

I've been told this idea was already mentioned, but it has been ignored
for some time:

https://git.issues.gerritcodereview.com/issues/40000039

The sooner it's addressed, the better since it means less personal
information leakage.

> After all, if you leave series of commits that stress the fact that
> you not just fail to keep, but do deliberately avoid to keep, a
> reliable record of when you made your changes, half the value of
> keeping your work in source code management system vanishes. When
> somebody comes to your project and says certain parts of your code
> were stolen from their proprietary IP, wouldn't you rather be able
> to produce the record of who did what at which time to refute their
> claim by showing that your project members invented the code long
> before they claim they were stolen from them?

Thank you for bringing this up. This was not an angle I considered when
writing my repo git-privacy, but now I'll definitely warn about it there.

Your feedback above would not apply to the UTC time zone proposal I
linked to though. There is a good reason to implement it and, as far as
I can think of, no reason not to.