Dura is a background process that watches your Git repositories
141–150 of 207 posts
Re: Dura is a background process that watches your Git repositories
#142Hmmm...rm -fr .git Now what?
Re: Dura is a background process that watches your Git repositories
#143As 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
#144Cool 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.
Re: Dura is a background process that watches your Git repositories
#145Earlier 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.
Re: Dura is a background process that watches your Git repositories
#146Not quite sure how suspending my editor and returning to the shell would help ;)
Re: Dura is a background process that watches your Git repositories
#147As 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…
I’d just never heard of it before.
Re: Dura is a background process that watches your Git repositories
#148Earlier 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!
Re: Dura is a background process that watches your Git repositories
#149Earlier 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...
Re: Dura is a background process that watches your Git repositories
#150I 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 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.