3 ms·

If nothing else to see and learn from your own history. Imagine a rich 20 year history of commits. Even if it was all the most basic system with just branches a

If nothing else to see and learn from your own history. Imagine a rich 20 year history of commits. Even if it was all the most basic system with just branches and commits and merges. I am still a source control simpleton after 20 years, but having a few branches using git is rather trivial.

ant6n 5y ago
Well there must be 20 years worth of backups. I wonder whether there is a way to turn 20 years of zip files storing different versions into a git repository, using the dates of the zip files, the dates of the files inside and perhaps the name of the zip files. Bonus points for detecting branches.
- masklinn 5y ago
  > I wonder whether there is a way to turn 20 years of zip files storing different versions into a git repository, using the dates of the zip files, the dates of the files inside and perhaps the name of the zip files. 'course there is. While Linus didn't bother, there are people who rebuilt the Linux history from the tarballs, and you can `graft` the historical sequence and the "real" one to get something of a continuous history from 0.01 to today. It's a lot of work though, old archives often contains partial garbage data (many of the rebuilt linux history incorrectly attribute various historical commits to 2007)
- jeltz 5y ago
  Yes, PostgreSQL did this when they switched from CVS to git. They used that as an oportunity to prrpend the history woth the contents of some ancient tarballs that they had.
- hahamrfunnyguy 5y ago
  Assuming there is a folder for each release, all you would have to do is commit the first release then each subsequent release. So after the first release, for every release delete all the files in the folder except the .git folder and copy the next set of source files in and commit. Doesn't account for branches, but seems like this would work and could be done quickly with some shell script.
- pferde 5y ago
  I did exactly that at work, when I inherited maintainership of a legacy internal software program, which until then has been developed with the same "version control" approach as DF - a folder/zipfile per release or per feature branch. As a bonus, it is something that has to run on three different operating systems, and the source code for each has been kept separately, and synced manually every now and then. Granted, it was only like a dozen or so releases and not 20 years worth of development like DF, but that's just a matter of scale, not of principle. :)

ant6n 5y ago

Well there must be 20 years worth of backups. I wonder whether there is a way to turn 20 years of zip files storing different versions into a git repository, using the dates of the zip files, the dates of the files inside and perhaps the name of the zip files. Bonus points for detecting branches.

masklinn 5y ago
> I wonder whether there is a way to turn 20 years of zip files storing different versions into a git repository, using the dates of the zip files, the dates of the files inside and perhaps the name of the zip files. 'course there is. While Linus didn't bother, there are people who rebuilt the Linux history from the tarballs, and you can `graft` the historical sequence and the "real" one to get something of a continuous history from 0.01 to today. It's a lot of work though, old archives often contains partial garbage data (many of the rebuilt linux history incorrectly attribute various historical commits to 2007)
jeltz 5y ago
Yes, PostgreSQL did this when they switched from CVS to git. They used that as an oportunity to prrpend the history woth the contents of some ancient tarballs that they had.
hahamrfunnyguy 5y ago
Assuming there is a folder for each release, all you would have to do is commit the first release then each subsequent release. So after the first release, for every release delete all the files in the folder except the .git folder and copy the next set of source files in and commit. Doesn't account for branches, but seems like this would work and could be done quickly with some shell script.
pferde 5y ago
I did exactly that at work, when I inherited maintainership of a legacy internal software program, which until then has been developed with the same "version control" approach as DF - a folder/zipfile per release or per feature branch. As a bonus, it is something that has to run on three different operating systems, and the source code for each has been kept separately, and synced manually every now and then. Granted, it was only like a dozen or so releases and not 20 years worth of development like DF, but that's just a matter of scale, not of principle. :)