Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dura is a background process that watches your Git repositories

github.com

Post reply on HN
Print view View original

181–190 of 207 posts

Re: Dura is a background process that watches your Git repositories

#181

Post by andybak »

int_19h wrote: post #180
andybak wrote: post #177

A 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?

It is a backup but it's a partial backup that excludes:

1. everything else on your system (potentially - a lot of stuff depending on your workflow

2. everything you've .gitignored (you 100% sure that's all ok?)

3. changes not yet pushed

4. branches that don't exist on remote

5. git stuff that's invaluable for disaster recovery

6. git stashes

and probably other things i haven't thought of.

Backups should be:

1. Offsite

2. Automated

3. Recent and up to date

4. Comprehensive

Git workflows usually only handle point 1

Re: Dura is a background process that watches your Git repositories

#182

Post by da39a3ee »

andybak wrote: post #177

A 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 common move is:

1. Commit everything 2. Make a temp branch (remember that “branches” are just labels for a commit; they cost nothing) 3. Switch back to the first branch 4. Use git reset to uncommit the last few commits 5. Clean up the code and commit it properly, with a good commit message 6. Run tests and check the diff from your temp branch to check you didn’t make a mistake when cleaning up

This tool Dura is totally unnecessary for people who are comfortable with git.

Re: Dura is a background process that watches your Git repositories

#183

Post by da39a3ee »

This tool Dura is totally unnecessary for people who are comfortable with git.

People are 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 common move is:

1. Commit everything

2. Make a temp branch (remember that “branches” are just labels for a commit; they cost nothing)

3. Switch back to the first branch

4. Use git reset to uncommit the last few commits

5. Clean up the code and commit it properly, with a good commit message

6. Run tests and check the diff from your temp branch to check you didn’t make a mistake when cleaning up

Re: Dura is a background process that watches your Git repositories

#184

Post by maleldil »

dv_dt wrote: post #3

I always wanted a utility to run in the background, look for changes, run unit tests, and if they pass automatically do a side commit noting it. This looks close.

I think you can do something like that with `watchexec` (or `entr`, if you prefer that):

watchexec -c -e go 'go test ./... && git commit -am "Tests pass"'

Re: Dura is a background process that watches your Git repositories

#185

Post by dijonman2 »

Quekid5 wrote: post #80
whoomp12342 wrote: post #72

Earlier quoted context omitted.

different strokes for different folks. I like to use my staging area as "I want to save this" until I get to a logical stopping point in my work. Then I commit it with its descriptive message. This way I can diff/reset against master while making progress, and show a nice clean progression of my work for who reviews it. also, sometimes I just lump the whole thing into a PR because there arent more than one logical un…

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.

Re: Dura is a background process that watches your Git repositories

#186

Post by avgcorrection »

stavros wrote: post #138
avgcorrection wrote: post #136

Earlier quoted context omitted.

Don’t use a fancy tool to implement a simple tool? I’m sure that’s a rule somewhere.

Ah, I'm of the "whatever gets the job done with the least amount of effort" school.

Using libgit2 bindings is the “least amount of effort” to implement periodic backup? And even if it may corrupt your repo?[1]

[1]: https://news.ycombinator.com/item?id=29786422

Re: Dura is a background process that watches your Git repositories

#188

Post by playing_colours »

grishka wrote: post #133
abcd_f wrote: post #53

As a sidenote - “dura” is a common and fairly rude Russian word for “fool” or “imbecile” as applied to women. Perhaps it was intended, but I can’t quite make a connection.

I thought most every Russian was over it after laughing for a bit about the last name of the VKontakte founder, Pavel Durov. At least I didn't make this association immediately when I saw the name of this project.

To me the last name of Durov makes an association with “someone who fools”, connected to the verb “дурить” - “durit” - “to fool”.

Re: Dura is a background process that watches your Git repositories

#189

Post by kadoban »

saila wrote: post #150
kadoban wrote: post #49

Earlier quoted context omitted.

Automatic commits is generally not a good idea. Commits are supposed to be meaningful chunks of work, and meaning requires manual effort. Automatic pushing is also probably not great. If it's just a backup mirror of some kind maybe, but otherwise you should be doing something like intentionally pushing what you're trying to share. I don't really think that backups should be tied to git. There's already good backup so…

For regular commits, sure, but for snap-shotting your work, I think it's fine. The backup branch would never be shared with anyone else, as you'd either push it to your own workspace/fork or to a clone on a mounted disk. For this type of ephemeral backup of code-in-progress, I think storing it in git would be really convenient, because you'd just use standard git commands to find what you're looking for without havin…

Convenience could make it worth it. I can't say I'm all that convinced though, because you'll have to learn new concepts (and likely new commands, unless you're a git guru) about the backups anyway.

Re: Dura is a background process that watches your Git repositories

#190

Post by [deleted] »

clktmr wrote: post #176
kazinator wrote: post #166

I 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`.

[deleted]
Post reply on HN