I would argue the author probably could have even used SVN (not that I would recommend that at all) given he did some pretty manual scripting stuff (looping through commit ids etc).
Of course it his hard for me to tell with out seeing his exact repository (files).
"a hundred other programmers had copies of them." isn't a problem/cannot happen with svn because svn uses a single master repository. Fix it, and everybody can fetch it.
That leaves the "going back in time" step. That isn't easy with svn. If you have a backup of your repository, you can create patches for the commits made after it, restore from backup, and replay those you want to keep.
If you don't have a backup, the svn administrator can use svnadmin to dump and restore revisions and remove them (http://superuser.com/a/315138). I think that will be a lengthy operation if your repository has lots of history. It also requires free space to create a copy of your reporpsitory. Disclaimer: I have never used this tool.
Maybe I'm just too young to have a good perspective on this (due to only becoming a developer after git was fairly well established), but I thought that version control itself is supposed to be your backup
(Decentralized version control is only slightly different; if you lose the 'main' repository and don't have an exact clone (aka a backup), you may be able to glue together something from other repositories that is close to or equal to what you had, but there is no way to know for sure)
its rare, but sometimes a repository can get damaged beyond repair. keeping it inside of a cloud storage directory like google drive, dropbox or similar makes it prone for fatal errors.
in such a scenario a backup of the full repository is required. in gits case, remote sources can fill the 'backup' role pretty easily, as everything gets pushed to a remote server. this is obviously not enough safety if you're a bigger enterprise, they'll need additional safety guards/backups, but its sufficient for most people.
It is, if you're going to simplify it so far as to avoid the problemspace by nomenclature. It's just transforming nonlinear events into a linear sequence! I guess multithreading is also a fundamentally simple concept, in that vein.
I know abstraction is out of fashion these days, but it may have helped a little in organizing things. Abstraction, when used properly, can almost always make complicated things more simple.
Basically, if a regular person had created Git, and not a demigod, would it even have become what it is?
as a user, I'll take premature optimizations over slow as balls any day.
But, wtf do I know, I'm just some regular person.
> without losing the commit history and messages
Otherwise a "partial checkin" (which was exactly what "co-worker X" did) would have worked fine.
Git fails often for the "basic" use cases. I won't lie. The number of options is intimidating for a beginner and one can easily get themselves into trouble. This is why there are Git guides and tutorials and UIs and they are all ultimately unsatisfying when you're a beginner.
However the use case discussed in this article is NOT a beginner use case. It is an advanced case and the fact that Git is an advanced tool that supports it (both natively with git-filter-branch, as the author found out, and ad-hoc-ly as was their original plan is a testament to the power of the system.
Tell me how you would better achieve the requirements that were the premise for this article in a different VCS?