Live data from Hacker News

Dura is a background process that watches your Git repositories

github.com

71–80 of 207 posts

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

#71
post #58

Cool tool! It's kind of insane to that in 2022 were still dealing with "save early, save often." Our tools are so antiquated. Storage is cheap and computers are fast, every keystroke should be persisted somewhere I can recover from rather than having to manually save and commit works in progress.

IntelliJ does it, and you can even look at the local history and go back as far as you like.

It's rare, but I have lost history once or twice, possibly after a computer restart. It's great when it works (which is almost always) but not foolproof.

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

#72
post #10

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. 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…

What you're describing is how git should be used. I would add it's important to push your branch to the remote just in case something happens to the local copy. I tend to squash/rebase to get the same type of results, but I can't imagine not saving work regularly or being concerned with the commit history while I'm actively working.

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 unit.

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

#73
post #8

This is an interesting concept. I'd think it would need some kind of system tray icon to be aware if it stops running, otherwise, it might provide a false sense of security and you could lose work because you thought you were safe but Dura actually crashed three days ago. It also probably needs some sort of automatic syncing to a remote repo, so it isn't affected by spilling your coffee on your laptop.

If there was a machine-parseable `dura status` command, a Hammerspoon menu bar icon could poll that every N seconds and make a status icon!

I love Hammerspoon so much.

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

#74
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.

Also Spanish or Portuguese adjective in feminine form, meaning: "hard", "resistant", "harsh" etc.

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

#76

Cool tool! It's kind of insane to that in 2022 were still dealing with "save early, save often." Our tools are so antiquated. Storage is cheap and computers are fast, every keystroke should be persisted somewhere I can recover from rather than having to manually save and commit works in progress.

Navigating in this history might be a challenge. But I agree. My disk is filled by dozens of random docket images yet few megabytes of diffs are not stored.

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

#77
post #40

Honestly I feel a bit weird running this process that's going to watch all my git repos and commit things like that. Also, if my files are saved, then what am I recovering? I use VSCode and if my computer crashes it'll just recover the unsaved files automatically. That's useful.

The docs say it only watches repos you tell it to

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

#78
post #10

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. 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'll just throw out there that ever since I picked up Doom Emacs and the associated Magit, I have been doing the same thing and loving it, I'll commit every time I finish writing a logical scope of code, and then commit and push and know that everything is there in case anything happens, it also has made my commit comments much more descriptive as I know am actually able to describe exactly what the commit has done beyond "Added feature X, refactored function Y". Big fan of the continuous commit workflow.

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

#79

Seems like a nice tool, but if you really used git, I don't really see how this situation described at the readme.md could happen :-) you think you just lost days of work

> if you really used git That really doesn't mean anything. > I don't really see how this situation described at the readme.md could happen :-) Start working on a big and complicated refactoring, don't commit because everything's broken and in flux, run the wrong command and lose your changes-in-flight somehow (reset the working copy, revert a file, overwrite a file incorrectly, ...).

Yep, this. Exactly like the docs say, you could recover entire directories after an accidental reset, or just avoid having to ctrl+z in your file 40 times.

I've been fortunate to "only" lose about 2-3 hours of work to mis-typing in git in the last year. It could have been 2 days or so if I was unlucky. For 2-3 hours of work it's maybe not worth installing this tool, but I'm definitely thinking about it because it's so much better than potentially losing 2 days.

"Commit often" doesn't work for me a lot of the time, I'd spend up spending almost as much time rebasing and patch committing as I would in dev/refactor. When you're exploring you try 5 things for every one that works, and it's not apparent til later which thing you want to keep. Committing junk every 10 minutes and then committing a rollback for most of it isn't ideal.

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

#80

Earlier quoted context omitted.

What you're describing is how git should be used. I would add it's important to push your branch to the remote just in case something happens to the local copy. I tend to squash/rebase to get the same type of results, but I can't imagine not saving work regularly or being concerned with the commit history while I'm actively working.

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.)

Post reply on HN