I use ZFS, and on my home directory I have ZFS snapshot every minute for the last hour and every hour for the last 24h. It saved me so many time.
Is there no performance hit for doing snapshots every minute?
No it is basically free.
Dura is a background process that watches your Git repositories
191–200 of 207 posts
Re: Dura is a background process that watches your Git repositories
#192A 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…
> 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". You’re thinking about commit wrongly. You should commit all the time, and make use of branches liberally, and push branches to a remote for backup. Then, you should form your “permanent” commits from that work. The thing is, you have to get comfortable with git. For example, one…
> You’re thinking about commit wrongly. You should commit all the time, and make use of branches liberally,
I agree - but that doesn't invalidate my original statement. I think you might have misunderstood my point. See my other reply above.
Re: Dura is a background process that watches your Git repositories
#193Earlier quoted context omitted.
> 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". You’re thinking about commit wrongly. You should commit all the time, and make use of branches liberally, and push branches to a remote for backup. Then, you should form your “permanent” commits from that work. The thing is, you have to get comfortable with git. For example, one…
> You’re thinking about commit wrongly. You should commit all the time, and make use of branches liberally, I agree - but that doesn't invalidate my original statement. I think you might have misunderstood my point. See my other reply above.
Yes, I think I stick to my ground. I'll address your points below. There are two camps here:
1. A large number, possibly a majority, of people who aren't yet familiar enough with git. Those people think of commits as being final: a commit is what you will push to the remote, your colleagues will see, and gets stored in public git history forever. They haven't yet learned that branches cost nothing, how to work with temporary branches, and how to create a new series of commits from already-committed work.
2. People who know git well and are the complement of the above set in all ways.
I'm sure you're right that backup systems have their place, but your comments here about how git shouldn't be used for backups are aligning with the camp (1) folks and making it harder for them to see that git can be used to save their work frequently, once they learn git better. Ultimately, positions like the one you're taking contribute to people developing misconceived tools such as TFA.
> 1. everything else on your system (potentially - a lot of stuff depending on your workflow
Sure -- backing up random files is good. I use google drive for that personally.
> 2. everything you've .gitignored (you 100% sure that's all ok?)
Yes, I don't worry about this. .gitignore is itself under git's control, so whatever's gitignored for me, is gitignored for my colleagues, therefore the project works without standardized content in those file paths.
> 3. changes not yet pushed
What reason is there ever to not push a branch that contains work you wouldn't want to lose? Planes and other no-network situations is one: I just push as soon as I'm on network. I never leave valuable work unpushed if I have a network connection.
> 4. branches that don't exist on remote
Why haven't you pushed them?
> 5. git stuff that's invaluable for disaster recovery
Not sure what you mean here
> 6. git stashes
Yes, good point to raise. Store work you're not prepared to lose in branches, and push them. You can stash it as well if that's convenient.
You probably know this, but the biggest hurdle newcomers to git face is they don't understand that branches are cheap, and they don't understand how easy it is to undo changes by using temp branches with `git reset --hard` and `git checkout`. Rather than telling them to supplement git with a backup system, it would be better to teach them to get comfortable using git. TFA is an extreme example, talking as if ctrl-z undo is an inevitable workflow for a git user when, in fact, it's only something that beginners do for more than trivial undo operations.
Re: Dura is a background process that watches your Git repositories
#194Earlier quoted context omitted.
> You’re thinking about commit wrongly. You should commit all the time, and make use of branches liberally, I agree - but that doesn't invalidate my original statement. I think you might have misunderstood my point. See my other reply above.
Yes, I think I stick to my ground. I'll address your points below. There are two camps here: 1. A large number, possibly a majority, of people who aren't yet familiar enough with git. Those people think of commits as being final: a commit is what you will push to the remote, your colleagues will see, and gets stored in public git history forever. They haven't yet learned that branches cost nothing, how to work with t…
> I use google drive for that personally.
I don't trust any backup that requires me to remember and take a manual action.
> > 3 . changes not yet pushed > > 4. branches that don't exist on remote > Why haven't you pushed them?
Fair point. Because I'm mainly working in public repos, it's psychological. It requires some degree of mental effort whenever I think about pushing something because it's then in public for people to see. I judge people on their public commits so I rather suspect people will do the same as me. "Naming things is one of the hard problems in computer science" - a public commit requires several naming decisions (commit message, branch, deciding "foo" is not a great name for a variable). I sometimes don't want to break my flow to make those decisions. And sometimes that means I put off a commit for longer than I should.
Whereas - my backup happens automatically and continually. It's not tied to my indecision, choices or personal failings. It just works.
So - I strongly recommend everyone uses version control. And I strongly recommend they augment it with AUTOMATIC off-site backups.
Re: Dura is a background process that watches your Git repositories
#195I 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`.
How good is that for boo-boo situations that you caused outside of the editor entirly? Like deleting a file?
Re: Dura is a background process that watches your Git repositories
#196Earlier quoted context omitted.
You can still get do what you want if you commit every 60 seconds (or whatever). It's just about postponing any and all cleanup activity until you're ready to shared it with reviewers/the world. (... but of course, by all means do what works for you. Just be aware that you might be missing out on something because you're artificially constraining your workflow.)
A commit every 60s sounds terribly inconvenient unless it’s automatic. I share OP’s workflow patterns and it works for me. I also don’t use an IDE.
I don't mean 60s literally. I mean arbitrarily small commits at your own convenience.
You don't need to have even remotely working code when you commit, is the point. You just commit whenever. (It's almost like saving files, just commit.)
I think the word 'commit' might have been a mistake, now that I think about it. Maybe 'snapshot' would have been better.
Re: Dura is a background process that watches your Git repositories
#197Earlier quoted context omitted.
Yes, I think I stick to my ground. I'll address your points below. There are two camps here: 1. A large number, possibly a majority, of people who aren't yet familiar enough with git. Those people think of commits as being final: a commit is what you will push to the remote, your colleagues will see, and gets stored in public git history forever. They haven't yet learned that branches cost nothing, how to work with t…
> I use google drive for that personally. I don't trust any backup that requires me to remember and take a manual action. > > 3 . changes not yet pushed > > 4. branches that don't exist on remote > Why haven't you pushed them? Fair point. Because I'm mainly working in public repos, it's psychological. It requires some degree of mental effort whenever I think about pushing something because it's then in public for peo…
Fair enough, that all makes sense. I do push branches and hope people won't look at them if they aren't connected to PRs :)
> I don't trust any backup that requires me to remember and take a manual action.
(Google drive has an automatic sync client thing like Dropbox so all it involves is having a special local folder where I put documents I want backed up. Or indeed git repos. https://www.google.com/drive/download/)
Re: Dura is a background process that watches your Git repositories
#198Earlier quoted context omitted.
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.
I just found that the Vim manual recommends, right in the doc for backupext, the use of the BufWritePre hook instead, so:
:au BufWritePre * let &backupext=("." . strftime("%y-%m-%d.%H:%M:%S"))
Re: Dura is a background process that watches your Git repositories
#199I built a similar tool a couple of years ago here: https://github.com/google/git-sync-changes Both save uncommitted changes in a hidden ref. Based on the README, the differences seem to be: 1. dura runs as a daemon while git-sync-changes is a one shot execution. 2. dura saves locally, while git-sync-changes syncs with a remote repo. 3. dura only does the save and the restore is manual, whereas git-sync-changes does b…
Do you have any comparison with https://www.sparkleshare.org/ too?
Thanks for the pointer; I had never heard of sparkleshare before.
It sounds like it addresses roughly the same use case, but I couldn’t find any technical details about it in its docs in order to see how it compares.
Re: Dura is a background process that watches your Git repositories
#200Earlier quoted context omitted.
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`.
How good is that for boo-boo situations that you caused outside of the editor entirly? Like deleting a file?
I suppose you know the answer, but in case anyone wonders: It won't help you. You can of course use it together with the `backup` option.