git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Dealing with corporate email recycling

From
Sean Allred <allred.sean@gmail.com>
Date
Mar 13, 2022, 15:21 UTC
Message-ID
<87r175amw2.fsf@gmail.com>
In-Reply-To
<01f301d836eb$5c7a6810$156f3830$@nexbridge.com>
<rsbecker@nexbridge.com> writes:
Show 14 quoted lines
> 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

Previous: rsbecker@nexbridge.comNext: Philip Oakley
Message 8 of 28 in “Dealing with corporate email recycling”
  1. Sean AllredMar 12, 2022
  2. Junio C HamanoMar 13, 2022
  3. rsbecker@nexbridge.comMar 13, 2022
  4. Sean AllredMar 13, 2022
  5. rsbecker@nexbridge.comMar 13, 2022
  6. Sean AllredMar 13, 2022
  7. rsbecker@nexbridge.comMar 13, 2022
  8. Sean AllredMar 13, 2022
  9. Philip OakleyMar 13, 2022
  10. Sean AllredMar 13, 2022
  11. Junio C HamanoMar 13, 2022
  12. rsbecker@nexbridge.comMar 13, 2022
  13. Junio C HamanoMar 14, 2022
  14. Philip OakleyMar 14, 2022
  15. Junio C HamanoMar 14, 2022
  16. Philip OakleyMar 14, 2022
  17. Sean AllredMar 15, 2022
  18. Philip OakleyMar 15, 2022
  19. Philip OakleyMar 13, 2022
  20. Sean AllredMar 13, 2022
  21. Philip OakleyMar 14, 2022
  22. Ævar Arnfjörð BjarmasonMar 13, 2022
  23. brian m. carlsonMar 13, 2022
  24. rsbecker@nexbridge.comMar 13, 2022
  25. rsbecker@nexbridge.comMar 13, 2022
  26. Sean AllredMar 13, 2022
  27. Sean AllredMar 15, 2022
  28. Peter KreftingMar 18, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.