By default these entries expire after 90 days. More details on the available options can be found in the `git-rev-parse`.Īs noted in the comments this method uses the reflog to find the commit in your history. You can checkout a commit by a specific date using rev-parse like this: Or you can `git commit` it to a separate branch. You would than use `git stash pop` to get it back. You can keep your work stashed away, without commiting it, with `git stash`. Then it seems that git branch NEW_BRANCH_NAME COMMIT_HASH will create a branch based around the state of the files at the time of that commit, or git checkout -b NEW_BRANCH_NAME COMMIT_HASH will create the branch and check it out (just make sure you have all your current files checked into the repo so you can revert back to them…) On the command line, it seems we can get a commit immediately prior to a particular date: git rev-list master -max-count=1 -before= (can we also fdo that relative to datetime?). If the repo is mirrored in GitHub, it looks like you can revisit the state of a repo if you don’t want to go too far back in time ( “simply add the date in the following format – in the place of the URL where the commit would usually belong”). Having got files backed up, -ish, into a git repo, the next issue is how students can revisit a point back in time. ipynb files via a hidden directory, perhaps via hidden Jupytext paired markdown files) rather than the notebook pre-commit actions might also be useful here… ipynb notebook files, actually backup a copy of them (perhaps as. One way of doing this would be tweak gitwatch to spot changed files and if they are. It strikes me that if students are working on notebooks, we really want to commit the notebooks cleared of cell outputs. # Example of viewing state of github repo at at particular time # # The following is probably not recommended. # It's most conveniently installed using bpkg package manager # automatic git add/commits for changed files # The gitwatch package uses inotify-tools to trigger
# inotify-tools gives us access to a directory monitor.Īpt-get update -y & apt-get install -y inotify-tools # But students won't remember to do that very often. # With git installed, we need to create a nominal user So I wonder: can we use gitwatch to back-up (ish) files in a student’s working directory in a provided container into a local persistent git repo mounted into the container? ( inotify itself provides handy tools for monitoring the state of the file system (for example, Monitor file system activity with inotify.) The gitwatch package uses inotify-tools to as part of “a bash script to watch a file or folder and commit changes to a git repo” (you can also run it as a service). The inotify-tools package wraps the Linux inotify command with a handy CLI wrapper. Note that I haven’t had a chance to test that any of this works yet! Noting, as ever, that sometimes students either don’t save, or accidentally delete, all their work (I take it as read that most folk don’t back-up: I certainly don’t ( “one copy, no back-ups”)) I started pondering whether we could create local git repos in student working directories in provided Docker containers with a background process running to commit changed files every 5 minutes or so. PS (suggested via / also add link to Wikipedia page for each story (thinks: that should be easy enough to at least partially automate…) Author Tony Hirst Posted on NovemNovemCategories Anything you want Leave a comment on Fragment – Searchable SQLite Database of Andrew Lang Fairy Stories Fragment: AutoBackup to git Propp morphology of each story), eg so I could easily search for stories with different structure types. It’d also be really interesting to come up with a way of tagging each record with a story structure / morphology (e.g. put together a fairy story entity model.explore generating book indexes based on a hacky pagination estimate.pull out first lines as a separate item.annotate stories with Aarne-Thompson or Aarne-Thompson-Uther (ATU) story classification codes (is there a dataset I can pull in to do this keyed on story title? There is one for Grimm here.I think I need to start working on my own “fairy story entities” model too…) Note to self – the db is intended to run as a full-text searchable db via a neater user inferface, ideally with some sensible facet-based search options (with facet elements identified using entity extraction etc.