From: Sean Allred <allred.sean@gmail.com>
To: rsbecker@nexbridge.com
Cc: 'Junio C Hamano' <gitster@pobox.com>,
git@vger.kernel.org, sallred@epic.com, grmason@epic.com,
sconrad@epic.com
Subject: Re: Dealing with corporate email recycling
Date: Sun, 13 Mar 2022 10:21:04 -0500 [thread overview]
Message-ID: <87r175amw2.fsf@gmail.com> (raw)
In-Reply-To: <01f301d836eb$5c7a6810$156f3830$@nexbridge.com>
<rsbecker@nexbridge.com> writes:
> I have another reluctant suggestion, but it depends on your industry,
> regulations, and other factors. In some sectors, there is a
> requirement to keep only some period of time worth of history. In
> fact, in some settings, keeping user identifying information beyond,
> say 7 years, actually is problematic. Pruning your history may be not
> only an option but required. An alternative is to use filter-branch to
> essentially tokenize the identities of past authors and keep those in
> a electronic vault somewhere. I have customers who are interpreting
> GDPR-like rules just such as situation, where employees gone 7 years
> ago and cannot be retained, by name, in the repos. I am not personally
> happy about that, because my own repo-OCD demands that I know exactly
> who did what until the end of time, but according to them, it actually
> violates the local regulations. I'm sure you have had conversations
> with lawyers, yes? ☹
I don't believe we've involved our legal team here (I'll follow up with
them internally), but that might be a spin-off discussion for folks who
know they're affected. It would seem that the design of Git makes
purging history on an ongoing basis problematic -- you would always have
at least one unresolvable reference to a parent commit. If this is a
real requirement from GDPR-like laws, either 'reasonable' VCS metadata
needs to be a specific carve-out in those laws -- but who the heck knows
what is 'reasonable' -- or as a project, Git needs to have an answer to
this situation and an ability to truncate history without otherwise
altering it.
It's also worth noting that even in the last five years, at our scale,
we've definitely run into the email-recycling problem already.
Being based in the U.S. and not having seen pitchforks about this yet,
I'd like to assume for the purpose of this discussion that we're keeping
all our history.
I think if the topic of legal implications of keeping history in
perpetuity is valuable to continue, we should spin it off into a
separate thread. Personally I'm not seeing what we (Git) could
realistically do about it other than provide recommendations and paths
forward -- which might require considerable development.
--
Sean Allred
next prev parent reply other threads:[~2022-03-13 15:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-12 22:38 Dealing with corporate email recycling Sean Allred
2022-03-13 0:03 ` Junio C Hamano
2022-03-13 0:26 ` rsbecker
2022-03-13 14:01 ` Sean Allred
2022-03-13 14:20 ` rsbecker
2022-03-13 14:41 ` Sean Allred
2022-03-13 15:02 ` rsbecker
2022-03-13 15:21 ` Sean Allred [this message]
2022-03-13 19:57 ` Philip Oakley
2022-03-13 22:40 ` Sean Allred
2022-03-13 23:16 ` Junio C Hamano
2022-03-13 23:23 ` rsbecker
2022-03-14 0:19 ` Junio C Hamano
2022-03-14 11:56 ` Philip Oakley
2022-03-14 21:24 ` Junio C Hamano
2022-03-14 22:25 ` Philip Oakley
2022-03-15 1:23 ` Sean Allred
2022-03-15 11:15 ` Philip Oakley
2022-03-13 12:20 ` Philip Oakley
2022-03-13 13:35 ` Sean Allred
2022-03-14 11:59 ` Philip Oakley
2022-03-13 15:51 ` Ævar Arnfjörð Bjarmason
2022-03-13 17:22 ` brian m. carlson
2022-03-13 17:52 ` rsbecker
2022-03-13 19:47 ` rsbecker
2022-03-13 22:23 ` Sean Allred
2022-03-15 1:27 ` Sean Allred
2022-03-18 21:22 ` Peter Krefting
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=87r175amw2.fsf@gmail.com \
--to=allred.sean@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=grmason@epic.com \
--cc=rsbecker@nexbridge.com \
--cc=sallred@epic.com \
--cc=sconrad@epic.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).