Live data from Hacker News

Dura is a background process that watches your Git repositories

github.com

141–150 of 207 posts

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

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

In brazilian portuguse it's also slang for "scolding".

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

#144
post #111

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.

> It's kind of insane to that in 2022 were still dealing with "save early, save often." Those of us who don't code in autosynced folders, that is. There is tons of software (IMO better than the approach in TFA) that has solved this problem for years now. Dropbox or Google Drive if you trust the cloud. Unison or looping rsync or syncthing if you don't.

I think you missed the point. Those tools can't do anything until you hit save. They're useful but still very limited.

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

#145

Earlier quoted context omitted.

> If they’re not then I’m just using a fancy VCS tool[1] for backup Yes you are; what's wrong with that?

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

But also don't use more tools than you need. And good backup isn't notably simpler than a VCS.

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

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

LOL — author here — I definitely didn't intend it that way, but it does kind of jive with "Git's" other meaning. I should have known that all 4-letter words are an insult in some language. I had originally named it "duralumin" after a magical metal in [a novel that I'm reading]( https://www.amazon.com/Well-Ascension-Mistborn-Book/dp/07653... ). I shortened it to "dura" after realizing that I can't even remember the n…

Not sure if it was obvious to you, but years after reading the novel I found out it’s not just a ‘magical metal’, it exists and is/was used in aircraft construction.

I’d just never heard of it before.

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

#148

Earlier quoted context omitted.

I usually commit often locally and push to remote right away. Then when I want to open up my PR, I use `git reset --soft ` where target is the local version of the target branch in my PR. That resets all the commits, but keeps all the changes in the staging area, and then I can clean up my history. Then I force push to override what's there. This works well for my workflow because we squash all commits into target br…

I never considered soft resets for my work flow (rewrite history with rebase -i). Funny how I use it for other things, but not this. Thanks!

sure thing. I actually just learned about it about a year ago and before then I was rebasing interactively too - this is so much easier!

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

#149

Earlier quoted context omitted.

I keep a draft PR open to keep track of this. Not has nice as vs-codes diff tool though.

You can still use VS Code's diff if you have the GitHub Pull Requests extension: https://marketplace.visualstudio.com/items?itemName=GitHub.v...

Anything that would allow a similar workflow in JetBrains IDEs?

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

#150
post #49
post #46

I used to run a simple rsync script that copied all my active projects to an external drive every 15 minutes. I figured that if I had a major issue, I'd only lose a limited amount of work, which I could probably re-create without too much trouble. Lately, I've been using private branches in the early stages of feature development, but you still have to remember to push in case of hardware failure. I also rely on my I…

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 having to deal with another tool.

Post reply on HN