All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "nick" <nick@nicholasjohnson.ch>
Cc: <git@vger.kernel.org>
Subject: Re: Git Privacy
Date: Fri, 14 Jul 2023 09:45:04 -0700	[thread overview]
Message-ID: <xmqqbkgeqw6n.fsf@gitster.g> (raw)
In-Reply-To: <CU1SAE4WGP3X.3R7TTIWFSHGDI@anonymous> (nick@nicholasjohnson.ch's message of "Fri, 14 Jul 2023 09:22:44 +0000")

"nick" <nick@nicholasjohnson.ch> writes:

>> "nick" <nick@nicholasjohnson.ch> 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?

Actually it is the other way around, if I understand correctly.

Git could have been designed to discard that information like
previous version control systems, but it is another piece of
interesting information and made a conscious design decision to keep
it.  In other words, "is there any reason why we do not discard the
information?" is a wrong question to ask in the context of VCS.

I earlier said I am not yet convinced it is worth our time, and so
far I haven't heard anything new that may help me convince myself
yet.

Thanks.

  reply	other threads:[~2023-07-14 16:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-13 16:27 Git Privacy nick
2023-07-13 17:11 ` Junio C Hamano
2023-07-14  9:22   ` nick
2023-07-14 16:45     ` Junio C Hamano [this message]
2023-07-15  4:32       ` nick
2023-07-16 11:47         ` René Scharfe
2023-07-16 22:52           ` nick
2023-07-17  2:36           ` Junio C Hamano
2023-07-17  2:57             ` Junio C Hamano
2023-07-17  5:36               ` nick
2023-07-17 20:57                 ` Theodore Ts'o
2023-07-17 22:49                   ` nick
2023-07-17 16:37             ` Junio C Hamano
2023-07-16 23:07         ` nick
2023-07-16 23:27           ` Jason Pyeron
2023-07-17  4:20             ` nick
2023-07-18 21:59           ` brian m. carlson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqbkgeqw6n.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=nick@nicholasjohnson.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.