On Fri, 25 Jul 2025 at 04:58, Tomasz Rola <rto...@ceti.pl> wrote: […] > I think you may be conflating cvs use with need to setting up some > service and accessing via the net, even if only through the > localhost. But I do nothing like that. I just mkdir, cvs init and this > is mostly it. No need for big time administration, web interfaces or > whatnot. I edit the files with emacs and when I am done, I can either > save to disk and say "cvs commit" in a shell or do the equivalent in > editor.
Sorry, but this bashing of git is completely unsubstantiated. You're basically using the fact that CVS cannot be archived easily on a third-party service as a BENEFIT of CVS? How does that make any sense? Git absolutely can be used on a local machine without any internet access, too. "git init" is trivial and does not require internet access; in your prescribed scenario, you can use git the same way you're using cvs, if you don't care about the GitHub "social coding" or whatnot. To get a bit off-tangent, "editing" is deemed to be a major requirement these days. Twitter's inability to edit tweets was a major complaint by the "normies", and a major laughing stock, before such ability was finally added around the time of the acquisition in 2022. CVS does NOT allow novice users to edit commits. This is a huge deal-breaker for any use these days, just see how the "normal" people never understood the idea behind not being able to fix typos in their tweets. CVS does allow "pro" users an opportunity to edit commits, by editing the repo directly, but this is a fast path to create issues and a huge liability allowing the "pros" to ruin file history and then hide in the corner in shame for failing to keep the backups like a "pro" was supposed to. Git supports edits natively with `git commit --amend`, and with a native backup of all the edits through `git reflog`; this may be a bit more complex, but it's doable and only a quick search away. And it just works, after you get the gist of it. > > One more thing about simplicity of cvs. On my computer (running Parrot > OS ATM) I do: > > $: apropos -s 1 cvs | wc -l > 13 > > So, this many manpages to read about cvs. Whereas for git, I have: > > $: apropos -s 1 git|wc -l > 165 Git has a cleaner and more self-contained documentation where each git command has its own manual page. This separation allows each command to have extensive example section, specific to the use-cases of how each command could be useful in practice, something that wouldn't be possible if all commands were to be documented in the exact same manual page for just the main command itself, because then it'd be too bloated and you wouldn't be able to find anything, since too much scrolling/paging would be required. Again, this is a benefit, and not a drawback. It's also how modern software is written, by having separate files for each command, instead of one big monolith where the whole thing is a single piece in a single file. Additionally, Google Search has hugely regressed in its ability to search historical records. You basically cannot find anything more than a a few years old with Google these days. Just today, I've tried looking for the hptd(4) driver I wrote for OpenBSD in 2009, for HP 3D DriveGuard accelerometer sensor, which never got committed, probably because testers didn't volunteer to test it. You cannot find it with Google somehow. Trivial to find directly on marc.info with the subject line search, however. C.
