Keep a history of all the modifications to a text file

Question

I have a plain text file (not containing source code). I often modify it (adding lines, editing existing lines, or any other possible modification). For any modification, I would like to automatically record:

• what has been modified (the diff information);
• the date and time of the modification.

(Ideally, I would also like to be able to obtain the version of my file at a specific time, but this is a plus, not essential).

This is surely possible with Git, but it's too powerful and complex. I don't want to deal with add, commit messages, push, etc. each time. I would simply like to edit the file with vi (or equivalent), save it, and automatically record the modification as above (its diff and its time).

Is there a tool to accomplish this in Linux?

---

Update: Thanks for all the suggestions and the several solutions that have been introduced. I have nothing against git, but I explicitly wished to avoid it (for several reason, last but not least the fact that I don't know it enough). The tool which is closest to the above requirements (no git, no commit messages, little or nothing overhead) is RCS. It is file-based and it is exactly what I was looking for. This even avoids the use of a script, provides the previous versions of the file and avoids the customization for vi.

---

The requirements of the question were precise; many opinions have been given, but the question is not - per se - that much opinion-based. Then, obviously, the same goal can be achieved through a tool or through a script, but this apply in many other cases as well.

Answer 1

Give git a chance

I don't see why it is an issue to use a powerful tool. Just write a simple bash script that runs git periodically (via cron or systemd timers); auto-generate commit messages etc.

As others highlighted in the comments it is - of course - possible to create a local repository (see here and there for more details).

If you prefer to host your own remote repo, you'll need to set up a "Bare Repository." Both git init and git clone accept a --bare argument.

Borg backup

I can also recommend borg backup. It offers you:

• Timestamps
• borg diff (compare between snapshots)
• Pruning (get rid of older snapshots - say you want a snapshot for the current month every day but otherwise only one per month)
• Encryption (optional)
• Compression (optional)
• and much more...

The cool thing is that it is very flexible - it is easy to setup but give you a lot of options if you want so.

I once wrote a quick-start guide which might be of help.

Answer 2

There a couple ways that you could do this:

• vim
• emacs
• git
• inotify-tools
• git-annex (all-in-one solution)

Which are all detailed here:

Using Vim:

Then I'd recommend using undo history, which not only (as it's name suggest) relate to the act of undoing an action in the Vim editor, but also the one you save too. More here.

Adding the following to your .vimrc:

let vimDir = '$HOME/.vim'
let &runtimepath.=','.vimDir
" Keep undo history across sessions by storing it in a file
if has('persistent_undo')
    let myUndoDir = expand(vimDir . '/undodir')
" Create dirs
    call system('mkdir ' . vimDir)
    call system('mkdir ' . myUndoDir)
    let &undodir = myUndoDir
    set undofile
endif

Will make it so every changes/undo will be permanently kept under the directory undodir under your local vimDir, which is by default either .vim in your home directory, or other ones mentioned in the output of :version or --version on the commandline.

For even more control over your undo history, I'd recommend also using Undotree to complement the experience.

Using Emacs:

There is a similar named packages called Undotree, which does similar things. More information on Undo history here.

Using Git:

I'd recommend using git-autocommit, which is a small bash script, with git as it's only dependencies, that watch the current git directory (where you launch it) for any new files/or modified files, and commit them.

Given the nature of Git it keep every changes to the file, and while it wouldn't be suited for a production/serious project, it is a useful solution if you don't mind not having commit message/generic commit message (which you can always edit/add later on).

Launch it after navigating on the wanted git directory (which is first made with git init on a specific directory, more info on the official manual) like so:

screen -dmS namehere git-autocommit -i 1 -V

if you're using screen, for tmux:

tmux new -n namehere git-autocommit -i 1 -V

otherwise:

git-autocommit -i 1 -V

will suffice if you prefer to not background it.

Using inotify-tools:

I'd recommend using inotify-tools or more specifically inotifywatch which can detect and (as it's name suggest) watch a file/directory for changes, which you can then do action on it (like save it somewhere else, etc).

Here the flag to use with inotifywatch:

inotifywait -r -m -q -e close_write --format %w%f yourdirectorypathhere

and here an example Bash script using the above:

#!/bin/bash
inotifywait -r -m -q -e close_write --format %w%f directorytowatch | while IFS= read -r file; do
process $file

done

Where process can be anything you'd want, like tar if you want to make backup on file modification, or with rclone if you want to upload it somewhere...

Using git-annex:

I'd recommend git-annex which not only encompass Git but many other external tools, like inotify-tools, bash, tar, rclone, borg etc.

More info on here.

If you feel like reading the wiki/forum later on, you can also git clone it locally, for offline reading:

git clone git://git-annex.branchable.com

for the website, forum (it's all in markdown, so it's very fast to download...), and codebase (it's in Haskell!) etc

Answer 3

You could try the venerable RCS (package "rcs") as @steeldriver mentioned, a non-modern version control system that works on a per-file basis with virtually no overhead or complication. There are multiple ways to use it, but one possibility:

• Create an RCS subdirectory, where the version history will be stored.
• Edit your file
• Check in your changes: ci -l -m -t- myfile
• Repeat

If you store this text in your file:

$RCSfile$
$Revision$
$Date$

then RCS will populate those strings with information about your revision and its datestamp, once you check it in (technically, when you check it out).

The file stored in RCS/ will be called myfile,v and will contain the diffs between each revision. Of course there's more to learn about RCS. You can look at the manpages for ci, co, rcs, rcsdiff and others.

Here's some more information:

• If you skip creating the RCS/ directory, then the archive will appear in the same directory as your file.
• You "check in" a file with ci to record a version of it in the archive (the *,v file in the RCS/ directory). Check-in has the weird side effect of removing your file, leaving your data only present in the *,v archive. To avoid this side effect, use -l or -u with the ci command.
• You "check out" a file with co to reconstitute it from the archive.
• You "lock" a file to make it writable and prevent others from writing to it, which would create a "merge" situation. In your case, with only one user modifying the file, "locked" means writable and "unlocked" means read-only. If you modify and "unlocked" file (by forcing a write to it), ci will complain when you try to check the changes in (so, avoid doing that).
• Since you're the only one editing your file, you have a choice of scenarios: you can keep your file read-only (unlocked) or writable (locked). I use unlocked mode for files that I don't expect to change often, as that prevents me from accidentally modifying them, because they're read-only, even for me. I use locked mode for files that I'm actively modifying, but when I want to keep a revision history of the contents.
• Using -l with ci or co will lock it, leaving it writable. Without -l it will be read-only with co or it will be removed altogether with ci. Use ci -u to leave the file in read-only mode after checking its contents into the archive.
• Using -m. will prevent ci from asking for a revision message.
• Using -t- will prevent ci from asking for an initial message (when the archive file is first created).
• Using -M with ci or co will keep the timestamp of a file in sync with the timestamp of the file at the time of check-in.
• co -r1.2 -p -q myfile will print revision 1.2 of myfile to stdout. Without the -p option, and assuming that myfile is "unlocked" (read-only), then co -r1.2 myfile will overwrite myfile with a read-only copy of revision 1.2 of myfile. -q disables the informational messages.
• You can create "branches", with revisions like 1.3.1.1. I don't recommend this as it gets confusing fast. I prefer to keep with a linear flow of revisions.

So, if you prefer to keep your file always writable, you could use ci -l -M -m -t- myfile. You can use rcsdiff myfile to see the differences between the current contents of myfile and the most recent checked-in version. You can use rcsdiff -r1.2 -r1.4 myfile to see the differences between revisions 1.2 and 1.4 of myfile.

The archive file is just a text file, whose format is documented in man rcsfile. However, don't attempt to edit the archive file directly. IMO, the text-based archive file, the absolute minimal extra baggage (only a single archive file), and keyword substitution are RCS's biggest strengths and what makes it a great tool for local-only, single-user, single-file-at-a-time versioning. If I were redesigning RCS, I would remove the complications beyond this scenario (e.g. multi-user, branching), which I think are better handled by more modern distributed version control systems.

As with any command, there are some quirks; you should play around with test files until you understand the workflow you want for yourself. Then, for best results, embed your favorite options into a script so you don't have to remember the likes of -t-, for example.

Answer 4

Another approach, which will cover all files in a given file system, is to use a log-structured file system such as NILFS.

Such file systems append changes, they don’t replace data. This is effectively equivalent to continuous snapshotting (or rather, checkpointing), and allows you to revisit the file system at various points in the past. Older checkpoints are liable to be garbage-collected once they reach a certain age, but checkpoints can be turned into permanent snapshots, and it is possible to automate that, for example to keep one snapshot per hour for the last month, then one per day for six months, then one per week etc.

NILFS is well-supported on Linux and is quite effective when used for /home.

Answer 5

Gitfs gives the best of both worlds, at least if it works for you. It provides a view of a git repository where you can edit files and every version is committed automatically.

mkdir mnt
gitfs https://example.com/repo.git $PWD/mnt -o repo_path=$PWD/working_copy

After this, you can edit files in mnt/current, and every version of the files will be automatically committed to git and will also be accessible through mnt/history/*/*.

Note that the first argument must be a remote repository. Gitfs doesn't seem to work with a local repository: if it's bare, it instructs git to access the origin remote which doesn't exist, and if it's non-bare, Gitfs tries to push to it, which fails, and Gitfs won't tell you except via a debug message so you lose all your changes.

A word of caution: gitfs seems rather buggy and poorly maintained. Silent failures are a common problem (pass -o log=-,debug=true,foreground=true,… to attempt to diagnose). You need to enable user_allow_other in /etc/fuse.conf, because the argument manipulation is buggy. It's the right concept, but I can't recommend it unless somebody takes up maintainership and fixes it up (I'm not volunteering).

Answer 6

I used a simple Bash script, possible called vers. Synopsis:

1. Run my usual editor on the files passed as args. After all editing:
2. For each file, look for the highest name like file.V[0-9][0-9].
3. If different checksum, cp -p the next higher version, and chmod 400.
4. If no previous version, make file.V01
5. Declutter any excess to a _VERSIONS subdirectory.

Helpful for establishing what you changed, and on what days.

Answer 7

You might want to take a peek at src (it stands for Simple Revision Control), a lightweight system to manage independent files (not whole projects). It is available on Debian (small wonder), or easy to install yourself.

Answer 8

You may want to create a function that does the tedious part for you ?

For exemple (note: I do not know git yet, so I just put "placeholder git commands" that you may way to change to make it work)

myvim () { vim "$@"  # put the arguments to myvim after vim (this allows you to add options, too)
           # and then the auto-commit part here. Note: I do *not* know git yet... fix where needed
           # I assume you are in the right directory for git init...
           { git init ; gid add ; git commit ;}
           # or if git add needs the names: (may want to get rid of options in args...)
           # { git init ; git add "$@" ; git commit ;}
           # or
           # { git init ; for f in "$@"; do git add "$f" ; done ; git commit ;}
}

You may want to replace the ";" between the commands with "&&" to ensure the next step is only done if the previous one returned 0

Answer 9

You are correct that revision control is the way to go. Yes git is way too complex. There are other revision control tools. The modern easy to use ones are Subversion (svn) and Mercurial (hg).

• subversion is non-distributed, non-locking, but supports locking, and has a global revision number.
• mercurial is distributed, non-locking (is like git, but easier to use).

Both are easy to use.

What is hard about git

Many people have commented that git is no harder to use than other tools with respect to init, add, commit, and push. This is nearly true (except that for git to do a commit you need to do add then commit (this is a 200% of the essential effort).

The problem comes when you start doing what a revision control system is designed for. Up to this point you have gain no benefit. You are only investing in revisions, in the hope that they will be useful. In the same way that making a back up is of no benefit (restoring a backup is of benefit).

The difficulty comes with analysing history and time travelling. There are many gotchas here, and there are no good free graphical tools. svn and hg are much better behaved, have a good easy to use command line and GUI.

Answer 10

? notepad++ according to this thread, which seems semi reliable https://answers.microsoft.com/en-us/windows/forum/all/notepad-edit-history/29de4e36-fd5b-48f2-8aea-b92992f9f8ba