The file org-save-clock.el is used to store two kinds of information:
- the active clock if emacs is shut down while a task is active
(gets stored in
org-clock-stored-resume-clock)
- the history of the n last clocked tasks (in a list of conses in
org-clock-stored-history), where n is determined by the
number stored in org-clock-history-length (default is 5)
Whether both of these variables are saved to the file depends on
the setting of org-clock-persist. If you set it to t both
informations are kept.
A short look at the source code in org-clock.el reveals that the
org-save-clock.el file is read by the org-clock-load
function. It checks whether the file belonging to the recorded task
exists, and if yes, it prompts the user whether the clock shall be
resumed.
Important: The active clock is only saved to org-clock-stored-resume-clock
when emacs is shut down; this can be seen in org.el where the org-clock-save
function is added to the kill-emacs-hook.
The contents of org-clock-stored-history are used in more
places. But mostly it serves as a clock-in convenience when using
the org-clock-select-task interactive function that lets you
choose from the last few clocked tasks by using the tasks saved
in that variable.
The information in the initial line of the org-clock-save.el file (the host and date information in the org-persist line) is not used at all inside the code. The file gets loaded as lisp code and there this line is just a comment.
Now, after all these facts, to your question:
Is it safe to add org-clock-save.el to the .gitignore file?
If you want to be able and resume a clock on computer B that you
clocked in to on computer A before shutting down emacs on A, then
you would need to have it synced. Else you lose the information of
the active clocked-in task.
But on the other hand, your loss is not
big, because the more important state is always conserved in the
tasks in the org files themselves, where for each clock interval
you have a CLOCK line, and org will warn you if there is a
dangling clock item.
Actually, I think git is anyhow not the best thing for syncing such
state files. I think it is easier to keep these frequently changing
state files on a dropbox-like service. Else your commit history
fills up with a lot of trivial stuff. Git is good for the rest of
the emacs.d directory to track the configuration changes. So, my
personal choice would actually be to define the position of the
org-clock-save.el file to be on a dropbox-like storage and take
it out of the git repo (you could change the location by setting
another path by redefining the org-clock-persist-file variable).
The whole clock saving mechanism naturally falls short if there are
two open emacs sessions working at the same time with the
org-clock-save.el file or also if you forget to sync. This can
lead to minor conflicts (but that is trivially true for many use
cases where files are synched but do not get locked). However, as
already noted: The most important information is kept in the org
files themselves (the CLOCK lines), so the information there is
authoritative and overrides the state information in
org-clock-save.el.
