This is really cool. One drawback is that it seems to touch the index, which I believe should be avoided, since it can disrupt the users workflow. I experimented with something similar a few years ago and avoided the index. My learnings are partially documented in the repo.[1]
Dura is a background process that watches your Git repositories
171–180 of 207 posts
Re: Dura is a background process that watches your Git repositories
#172I use this, in my .vimrc: :set backup :set backupdir=/home/kaz/.vimbackup :let &g:backupext=("." . strftime("%y-%m-%d.%H:%M:%S")) That's it. No messing around with git; protects files that are not in git, and can save you even in he face of "rm -rf .* *".
It's impossible not to note that emacs does this well too. Setting (setq backup-directory-alist `(("." "/home/user/some/dir/you/chose/backup/)) version-control t kept-new-versions 50 kept-old-versions 50) sets up a directory with many versions of every file ever edited. Additionally (setq auto-save-file-name-transforms `((".*" "/home/user/some/dir/you/chose/auto-save/" t))) does the same for even unsaved changes.
Vim doesn't do it "well" with the settings above, just "good enough". The time stamp suffix is calculated just once when you start Vim, set in the global backupext option. If we :e edit files in an existing Vim session, they all get backups with that time stamp. It needs to be calculated as a buffer-specific value of that option, if there is such a thing, on every new edit.
Re: Dura is a background process that watches your Git repositories
#173"Dura" in Russian language is "idiot". Specifically female idiot. Is it really hard for developers to enter word in google before naming application? This is ridiculous.
https://www.google.com/search?q=dura is not mentioning word in Russian for me - and I set number of results per page to maximum.
https://en.wiktionary.org/wiki/dura is also not mentioning it.
See also https://news.ycombinator.com/item?id=29785163 - it is not so clear insult anyway.
And anyway, it would be anyway fitting for git using tool (git also has meaning as pejorative, typically male)
Re: Dura is a background process that watches your Git repositories
#174Along similar lines, I've adopted a hyper-frequent commit pattern in git. I do a bunch of meaningless micro-commits as I'm making progress, and then rewrite them all into one or two meanginful commits once I've reached a working state of whatever I was trying to do. I find it's helpful for not losing work / easily backing up if as I'm going along I realize I want to change approach. (For the micro commit I have a git…
> Along similar lines, I've adopted a hyper-frequent commit pattern in git. I do a bunch of meaningless micro-commits as I'm making progress, and then rewrite them all into one or two meanginful commits once I've reached a working state of whatever I was trying to do.
Aren't you describing a feature branch? That frankly sounds like git 101.
Re: Dura is a background process that watches your Git repositories
#175Along similar lines, I've adopted a hyper-frequent commit pattern in git. I do a bunch of meaningless micro-commits as I'm making progress, and then rewrite them all into one or two meanginful commits once I've reached a working state of whatever I was trying to do. I find it's helpful for not losing work / easily backing up if as I'm going along I realize I want to change approach. (For the micro commit I have a git…
I have a `git snap` command that's similar to your `git cam` command with a small twist. The commit is added to a special snapshots branch that isn't checked out. I push the snapshots branch and don't rewrite it, but rather keep it around as an accurate chronological record of things I've tried, warts and all. I also like that `git diff` continues to show the changes compared to the last "real" commit this way.
Edit: I guess my script is somewhere between your `git cam` command and Dura in terms of functionality and complexity.
Re: Dura is a background process that watches your Git repositories
#176I use this, in my .vimrc: :set backup :set backupdir=/home/kaz/.vimbackup :let &g:backupext=("." . strftime("%y-%m-%d.%H:%M:%S")) That's it. No messing around with git; protects files that are not in git, and can save you even in he face of "rm -rf .* *".
There is also the `undofile` option, which stores your undo-history permanently on disk. You can also go to an earlier version of the file from 4 hours ago with `:earlier 4h`.
Re: Dura is a background process that watches your Git repositories
#177A lot of people seem to regard version control as an adequate substitute for an automated offsite backup. This strikes me as a dangerous habit. There are too many gaps between "what I want to commit to a repo" and "what I would hate to lose in the event of a total system failure".
It's better to keep the two things separate. I'm happy with Backblaze on all my machines - although they have a disturbing habit of making unannouced changes to their default exclude filter which tripped me up (no VM images I knew about. But adding .git directories nearly lost me data). You can override these filters but they really shouldn't be changing them without clear warning.
Re: Dura is a background process that watches your Git repositories
#178Along similar lines, I've adopted a hyper-frequent commit pattern in git. I do a bunch of meaningless micro-commits as I'm making progress, and then rewrite them all into one or two meanginful commits once I've reached a working state of whatever I was trying to do. I find it's helpful for not losing work / easily backing up if as I'm going along I realize I want to change approach. (For the micro commit I have a git…
> Along similar lines, I've adopted a hyper-frequent commit pattern in git. I do a bunch of meaningless micro-commits as I'm making progress, and then rewrite them all into one or two meanginful commits once I've reached a working state of whatever I was trying to do. Aren't you describing a feature branch? That frankly sounds like git 101.
Nope. A feature branch is still expected to have meaningful commits, and is usually used for collaboration between several coders. Its history doesn't get rewritten.
What OP describes is a temporary work branch that belongs to a single person, and has a bunch of meaningless commits. So nobody else should be using it - or if they do, they need to sync with the owner, since the latter can squash or otherwise mutate commits at any time.
Re: Dura is a background process that watches your Git repositories
#179Along similar lines, I've adopted a hyper-frequent commit pattern in git. I do a bunch of meaningless micro-commits as I'm making progress, and then rewrite them all into one or two meanginful commits once I've reached a working state of whatever I was trying to do. I find it's helpful for not losing work / easily backing up if as I'm going along I realize I want to change approach. (For the micro commit I have a git…
I do something similar, but with larger intermediate commits than yours and more meaningful messages. Then at the end, I do an interactive rebase, squash the ones I don't care about, and reword the final commit message based on the hints I left myself in the squashed ones.
I do a combination of the two: the first commit gets a meaningful (but still draft) message, and their follow-ups are all committed with "." as a message - but only until "switching gears", i.e. until a commit comes that is logically separate from the bunch before it. Those commits that have messages then provide logical milestones for squashing.
This breaks down sometimes if you have to switch back and forth between different parts of code, breaking the linear sequence. But even then, the messages make it easier to connect the pieces when it's time to clean up history before the pull request.
Re: Dura is a background process that watches your Git repositories
#180A lot of people seem to regard version control as an adequate substitute for an automated offsite backup. This strikes me as a dangerous habit. There are too many gaps between "what I want to commit to a repo" and "what I would hate to lose in the event of a total system failure". It's better to keep the two things separate. I'm happy with Backblaze on all my machines - although they have a disturbing habit of making…
Why shouldn't the repo be treated as a backup, if it is set up to be backed up? And who doesn't back up their work repos?