The problem with existing version control systems is not so much their complexity; it's the fact that there is such a wealth of information out there that it can be very difficult for beginners to see the forest for the trees (i.e., to figure out what they do and don't need to learn when they are just getting started).
This post is going to focus on
git, and describe how to control it from Emacs using an add-on package called
git is complex, but you don't need to learn a lot to use it productively for the purpose you describe.
I'm going to assume that you have
git installed (if you don't, get it here), and that you don't want to leave Emacs at all.
magit is a
git front-end for Emacs. It is available from MELPA and you can install it via:
On the off chance that you haven't enabled MELPA in your configuration, you can find instructions on how to do that here.
Setting up a repository
Let's say you have a folder called
~/writing in your home directory that contains one or more documents that you'd like to put under version control.
- Open the folder in Dired: C-x d
- Open a shell: M-x
git init and hit RET.
That's it. You now have a
git repository. There is no need to "register" it anywhere.
git is a distributed version control system; it does not require a remote server to track changes.
Checking the status of your repository
- Switch back to the Dired buffer that lists the files in your repository.
- Do M-x
You can think of the buffer that comes up as your "control panel" for working with your repository. For a new repository, it looks something like this:
Note that you can bring up the status buffer from any file or directory that belongs to the repository you set up earlier.
As you can see in the screenshot, there are three files in the repository that
git is not currently tracking. To tell
git to start tracking a file, you need to stage it: With point on the file you want to add, press s. The status buffer will then look like this:
After staging one or more files, you can commit them by pressing c c. This will bring up a buffer that looks like this:
Enter your commit message at the top and then press C-c C-c to finalize the commit. (To abort, press C-c C-k.)
The status buffer will then look like this:
If you make changes to a tracked file, they will be listed in a separate section ("Unstaged changes") in the status buffer:
To review the changes that you made to the file, navigate to the line that that says
Modified file-1.txt and press TAB:
To stage these changes, press s:
Viewing past commits
Finally, if you want to review past commits, you can press l l (that's two lower-case L's):
As usual, you can navigate the buffer that comes up with n and p. Magit will show the changes associated with individual commits listed in this buffer in a separate window.
From the shell:
git init: Initialize
git repository in current directory
From any file or directory associated with a
From the status buffer:
That's it. :)
magit-- github.com/magit/magit -- since you've already played around a little bit with it. You'll probably want to familiarize yourself with the command-line options so you'll have a better understanding of what
magitis doing. Emacs is not for non-coders, but you've been around the scene long enough to not be afraid of it -- :) You may also want to try playing with
vc-group of commands is to simplify the process of using VCSs. Unfortunately, they aren't as intuitive as to allow users with no experience to make a good use of them. On the other hand, systems like those you mention are very limiting, so that one quickly develops demands which they can't satisfy. gnu.org/software/emacs/manual/html_node/emacs/… there's a simplistic mechanism of keeping backups, but due to above, I'd rather recommend learning to use some VCS instead.
magitfor version control of my papers. It looks intimidating to start, but a) you don't have to learn it all at once, and b) it's enjoyable to use after getting over the initial learning curve. A good workflow also helps you discipline your writing tasks, as it encourages you to annotate what you're doing -- which is a great way to get a timeline of the evolution of the writing project.