4 ms·

This is not a "problem", this is why source control exists. You should never rewrite published history.

cabirum 4y ago
A value of a commit approaches zero as it gets older. After a certain threshold, no one will ever see it. Never say never; any reason why should we keep deadweight around?
- howinteresting 4y ago
  Your premise is incorrect. The other day I was looking around a repository that's been through many migrations, and found a commit from 2004 that was relevant to my interests.
- themerone 4y ago
  As long as a line code is in use, there is value in knowing who and when it was authored. If a 10 year old vulnerability is found in OpenSSL, it be nice to be able to investigate if it was an accident or an act of espionage.
tonnydourado 4y ago
A more conservative approach would be some sort of layered storage/archiving, I guess. The older the commit, the less likely it is to be used, so it could be archive in a different storage, optimized for long term. This way you keep the "hot" history small, while keeping the full history still available.
- howinteresting 4y ago
  That's generally how git packs are used at large organizations that host their own repositories. I'm sure GitHub does something similar.
crznp 4y ago
I don't think that your points are actually in conflict. If this is my source code, I want the whole history. I want that 10-year old commit that isn't used in any current branch. A build machine may not need any history: it just wants to check out a particular branch as it is right now, and that works too. But there is an intermediate case: Let's say that I have an issue with a dependency. I might check out that code and want some history to know what has changed recently, but I don't need that huge zip file that was accidentally checked in and then removed 4 years ago. If it were a consistent problem, perhaps you'd invent some sort of 'shallow' or 'partial' clone, something like this: https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ https://github.blog/2020-12-21-get-up-to-speed-with-partial-...
- howinteresting 4y ago
  True, though shallow clones have performance issues: https://github.com/Homebrew/discussions/discussions/225 https://github.com/Homebrew/discussions/discussions/225
torstenvl 4y ago
I don't think I can agree with that. Accidentally publish secrets/credentials? Rotate them yes but also remove them from the published history. Accidentally publish a binary for a build tool without the proper license? Definitely remove it (and add it to your .gitignore so it doesn't happen again!) You discover a major flaw that bricks certain systems or causes data loss? Retroactively replace the Makefile/configure script/whatever to print out a warning instead of building the bad build. I'm sure there are others.
- GoblinSlayer 4y ago
  AFAIK, copyright problems are fixed by just another commit without history rewrite. There's also no need to care about outdated credentials. Should bugs be fixed by deleting all history too? That code was buggy, bad, bad, must delete? VCS just becomes glorified ftp this way.

A value of a commit approaches zero as it gets older. After a certain threshold, no one will ever see it. Never say never; any reason why should we keep deadweight around?

howinteresting 4y ago
Your premise is incorrect. The other day I was looking around a repository that's been through many migrations, and found a commit from 2004 that was relevant to my interests.
themerone 4y ago
As long as a line code is in use, there is value in knowing who and when it was authored. If a 10 year old vulnerability is found in OpenSSL, it be nice to be able to investigate if it was an accident or an act of espionage.

tonnydourado 4y ago

A more conservative approach would be some sort of layered storage/archiving, I guess. The older the commit, the less likely it is to be used, so it could be archive in a different storage, optimized for long term. This way you keep the "hot" history small, while keeping the full history still available.

howinteresting 4y ago
That's generally how git packs are used at large organizations that host their own repositories. I'm sure GitHub does something similar.

crznp 4y ago

I don't think that your points are actually in conflict. If this is my source code, I want the whole history. I want that 10-year old commit that isn't used in any current branch. A build machine may not need any history: it just wants to check out a particular branch as it is right now, and that works too. But there is an intermediate case: Let's say that I have an issue with a dependency. I might check out that code and want some history to know what has changed recently, but I don't need that huge zip file that was accidentally checked in and then removed 4 years ago. If it were a consistent problem, perhaps you'd invent some sort of 'shallow' or 'partial' clone, something like this: https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ https://github.blog/2020-12-21-get-up-to-speed-with-partial-...

howinteresting 4y ago
True, though shallow clones have performance issues: https://github.com/Homebrew/discussions/discussions/225 https://github.com/Homebrew/discussions/discussions/225

torstenvl 4y ago

I don't think I can agree with that. Accidentally publish secrets/credentials? Rotate them yes but also remove them from the published history. Accidentally publish a binary for a build tool without the proper license? Definitely remove it (and add it to your .gitignore so it doesn't happen again!) You discover a major flaw that bricks certain systems or causes data loss? Retroactively replace the Makefile/configure script/whatever to print out a warning instead of building the bad build. I'm sure there are others.

GoblinSlayer 4y ago
AFAIK, copyright problems are fixed by just another commit without history rewrite. There's also no need to care about outdated credentials. Should bugs be fixed by deleting all history too? That code was buggy, bad, bad, must delete? VCS just becomes glorified ftp this way.