On Sat, 27 Oct 2018 at 08:23, David Christensen <dpchr...@holgerdanske.com> wrote:
Hi, I've noticed that you give a lot of good advice on this list. Now, I hope to return the favour :) ... > When I'm working on a file, I can do ten edit/ saves, or more. With a > versioning file system, the original file plus all the saves would be on > disk. This makes it easy to pick through them using standard tools. git is a "standard tool" these days. > But if the original file and all but the last save are in a version > control system (VCS), I would need tools that can reach inside the VCS. > Searching the manual pages of cat(1), grep(1), diff(1), and make(1) for git-cat-file(1) git-grep(1) git-diff(1) > 'CVS' just now, I found zero hits. This means I'd need to check them CVS WTF? :) > out. Now I'm back to what a versioning file system gives me automatically. > > > Furthermore, auto-commit on every save would put a lot of cruft into the > VCS, to be stored, backed up, and archived repeatedly and indefinitely. > If I try to remove the VCS auto-commits by hand, eventually I will > damage or destroy the VCS repository (e.g. Murphy's Law). Removing VCS > auto-commits mechanically would require developing and validating a > suitable work flow and tools, adding cost and limiting flexibility. git-rebase(1) Seriously, learn git. git's own documentation does not make that easy, but if you search more widely for information and persist, it will be extremely rewarding in the long run.
