-
-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Backup, Sync and git tracking #51
Comments
- git commit does not copy files any more - also remove git-lfs print - checks on git directory (and suppress inline help on --gitdir) TODO: contextualize in git-specific PR #51
While there are many ways of implementing back-ups and git tracking, the git model of a local, self-contained folder is the most elegant in my opinion. It is easy to keep track of and to cleanup (in contrast to a centralized repo with various branches for various files -- the number of branches would accumulate over time and be hard to maintain). To avoid double-tracking and conflicts with an existing, larger git repo, it should be possible to simply add a To let For a local install, the resulting files structure would look like:
A global install would be pretty much the same, except that a |
The model outlined above would ensure a solid backup whatever the user configuration. Restoring a previous bibtex would work with that sequence of commands:
The last line is not a perfect The sequence of commands above can be used for undos until the beginning of time, but it cannot be used for redo. Here an alternative sequence for
and for
Any new modification to the bib would empty futures (no redo after branching out). |
Upon saving of the bibliography, the following could work (a more efficient version would be needed to avoid moving around files if not necessary):
|
The model above is some kind of black box that leaves the implementation details to
Here plain Pros of black-box,
|
Now included in release 2.4. |
- with this command undo / redo also restore files that have been renamed (only if installed with --git-lfs option) caveat: these files will not be deleted in subsequent redos => redo only applies to tracked files Additionally to this addition, this large commit also overhauls the way git tracking works, by now using a history branch to do undo/redo, and main branch to save forward advances. This is cleaner and does not require a futures.txt file any more. New tests have been added to support both the --restore parameter and to make sure git does the right thing (only local install was tested -- in facts it seems the global install backup is buggy at this stage, more in next commit)
Despite what I first argued in #51, I now consider the central backup option to be the safest. More background work with git is needed to keep the size of the backup repo reasonable (e.g. remove what's older than X), but that is not urgent, by definition, and manual maintenance is possible (like removing the whole thing, since the backup dir is indicated in the config anyway). TODO: - initialize back-up git repo upon saving in case it was removed, or to make it work even without install.
Originally, git tracking feature was added in order to add safety to handling a global papers install.
Implementation details are now jeopardized with local install. Local installs are often git-tracked themselves, and nested git repos does not play good. Worse, papers git install might trigger commits to a directory where it is not expected to (fortunately it is off by default, so it still requires explicit user action to be enabled). In the original implementation, the git directory could also be separate from the bibtex file. If that was the case, the bibtex would be copied to the git directory upon saving, and a commit would be done. That works, but using git commands to revert or reset to a previous commit would then only affect the git repo, and not the original bibtex, making the overall behavior unintuitive. Clearly, some overhaul is needed.
While it is not entirely clear to me yet how that feature should evolve. The basic idea of using git to safeguard the bibtex, and undo unwanted changes, is still relevant IMO. Here a few options:
use git as an internal tool in papers, without explicitly asking about it. papers undo (and a new command papers redo) could be used to navigate git history. The git repo would be saved in a central papers dir, using different branches to handle different bibtex locations (using a slug of the full bibtex path as branch name, for instance). That could work even without a proper installation. Maybe. Issue: bibtex rename would break the flow by creating a new branch. We could live with that.
propose
hooks
upon bibtex save. Here a whole workflow could be fine-tuned by users. Could be used as internal to implement higher-level feature.add options to track files, sync with a remote server etc.
For now I'll just leave that issue open to collect ideas. Current simplistic implementation works OK.
The text was updated successfully, but these errors were encountered: