this post was submitted on 14 Aug 2024
-1 points (0.0% liked)
Linux Gaming
14952 readers
29 users here now
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
Resources
WWW:
Discord:
IRC:
Matrix:
Telegram:
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.