Junio C Hamano <gitster@xxxxxxxxx> writes:
> 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.
