Re: Git Privacy

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 17, 2023, 02:57 UTC
Message-ID: <xmqq5y6jjlcs.fsf@gitster.g>
In-Reply-To: <xmqqsf9njmc9.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 7 quoted lines

> and just use them), we should NOT be adding a "--privacy" option
> that picks rand(24)*60 as UTC offset and pretends that it the
> timezone of the author, and picks some random timestamp between the
> timestamp of the latest commit in the repository and the actual
> wallclock timestamp and pretends that is the author time.  After
> all, our project is not about coming up with a quality time
> obfusucation.

We could go to the extreme in the complete opposite, if we do not care about the quality of the "privacy" feature, and you could probably talk me into adopting below as long as the option or the configuration are not named with the word "privacy" in them (a "--useless-time" option, or a "core.uselesstime" configuration variable, are OK).

When the feature is in effect, all timestamps in commit and tag objects pretend to be in UTC timezone, and

 (1) the commits record the Epoch as its timestamps if there is no
     parent;

 (2) the commits record one second after the largest of the
     timestamps as its timestamps of all its parents;

 (3) in any case, the same (phoney) timestamp is used for author and
     committer.

 (4) the tags record the Epoch as its timestamp if they point at
     trees or blobs.

 (5) the tags record one second after the largest timestamp of
     pointee as their timestamp, if they point at tags or commits.

 (6) as the reflog is a local matter, its timestamp may be local,
     but it is OK if it ends up being just a useless number if that
     is more convenient to implement.

The resulting history will be shouting that "I am privacy conscious and hiding my activities behind a fake clock" in capital letters, which I would not call a quality design of a privacy feature, but it does completely dissociate the wallclock time from the recorded history without breaking the monotonicity of timestamps in the recorded history.

When the useless-time feature is in use, you cannot expect features like "git log --since" would work sensibly, but that is a given, I would guess.