Re: Git Privacy

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

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

Show 16 quoted lines

> René Scharfe <l.s.r@web.de> writes:
>
>> Not sure why there is no command line option for the latter, hmm.
>
> For two reasons.
>
>  * While using the GIT_AUTHOR_DATE environment variable is perfectly
>    adequate (after all, we did not have the option before Git 1.7.0,
>    released in Feb 2010), overriding the author time with "--date"
>    had a good reason to exist, unlike the committer timestamp.
>
>    Imagine you were relayed somebody else's changes, not via a
>    format that is kosher and acceptable by "git am", but somehow
>    managed to reproduce in your working tree.  If you also have
>    learned when and in which timezone the original author made that
>    change, you'd want to have a way to record it.

The point here is that tweaking the author time has a general utility that is wider than "I want to use a timestamp that is disconnected to the reality"---in fact, it is quite the opposite. The above example is using the option as a tool to record what actually happened in reality and not about using a fake time at which nothing related to the resulting commit happened. That is why I said that it "has a good reason to exist".

Contrasted to this, the committer timestamp is about when the commit was created, and there is no need to have an easy access from the command line like "--date" option does to tweak it [*]. It is updated to the current time when you "commit --amend" for exactly the same reason.

Show 8 quoted lines

> I think the existing two environment variables are very good place
> to draw the line.
> ...
> Needless to say, such a "privacy enhancing `date` command" can be
> used outside the context of Git, too.  My point is that it is not
> within the scope of this project to add an internal implementation
> of such a command and drive that from a command line option or a
> configuration variable.

And I still think this is a reasonable way forward. We have offered two environment variables for their use and it is up to them to use it when driving "git" binary from their environment. Anything more is a distraction to this project, I would think.

[Footnote]

 * As long as your system clock is reasonably accurate that does not
   need constant tweaking, that is.  If not, you have a more serious
   problem than tweaking the string on the committer line---none of
   the timestamp based heuristics like "make" not rebuilding things
   unnecessarily would be broken on your system.