Junio C Hamano wrote: > 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). I hadn't considered it in my other responses, but calling it --privacy would be a bad idea for exactly the reasons you laid out. Calling it --useless-time would be better. > 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. You're the expert on Git's internals and clearly know best how to implement this with the least amount of breakage. So I can't comment on that. I will say these points seem to be sufficient to satisfy the privacy use case. I don't think any more can reasonably be expected. > 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. Depending on one's threat model, revealing the fact that one is using a privacy feature/tool isn't necessarily a problem. I agree that perhaps a really high-quality implementation of a privacy feature could do this, but I think that's outside the scope and way too much to expect from devs as you said. > 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. There could be a warning in the documentation that this feature may cause breakage.
