File1, file2, file_3.new, etc would be bizarrely stupid. A home rolled solution involving rsync, tar, gzip, crons or inotify would also be bizarrely stupid.
https://en.wikipedia.org/wiki/List_of_version-control_software anything on that list that’s marked anything other than “active” as a more serious answer. So like DCVS, visual source safe, or bitkeeper. Anything that’s not getting bug fixes or maintenance.
Anything that doesn’t have significant enough usage to give confidence that bugs or glitches are being caught by common usage would be risky, since you don’t want to be the person to find that edge case.
There’s things other than git that aren’t wrong, but I see little compelling reason not to use the most ubiquitous tool.
Ubiquity is not always the most relevant decision. (Especially as most VCS which aren’t Git :-) are easy enough to understand - most of them are even easier than Git in my opinion.)
It depends on the outer circumstances, I think. Using the prevalent tool makes sense in existing environments (which is one of the reasons why many companies use SVN - it worked for them before Git existed and it still works for them, so why not?). For new projects, one-man teams and/or companies starting from scratch, Git might not always be the best choice.
File1, file2, file_3.new, etc would be bizarrely stupid. A home rolled solution involving rsync, tar, gzip, crons or inotify would also be bizarrely stupid.
https://en.wikipedia.org/wiki/List_of_version-control_software anything on that list that’s marked anything other than “active” as a more serious answer. So like DCVS, visual source safe, or bitkeeper. Anything that’s not getting bug fixes or maintenance.
Anything that doesn’t have significant enough usage to give confidence that bugs or glitches are being caught by common usage would be risky, since you don’t want to be the person to find that edge case.
There’s things other than git that aren’t wrong, but I see little compelling reason not to use the most ubiquitous tool.
Ubiquity is not always the most relevant decision. (Especially as most VCS which aren’t Git :-) are easy enough to understand - most of them are even easier than Git in my opinion.)
Of course it’s not the only factor, but all things being equal, the most prevalent tool should be preferred.
It depends on the outer circumstances, I think. Using the prevalent tool makes sense in existing environments (which is one of the reasons why many companies use SVN - it worked for them before Git existed and it still works for them, so why not?). For new projects, one-man teams and/or companies starting from scratch, Git might not always be the best choice.