Live data from Hacker News

Dura is a background process that watches your Git repositories

github.com

111–120 of 207 posts

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

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

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

#113

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.

Saving a log of every keystroke is basically what a CRDT for an editor does today. We really just need to make local editors behave more like Google Docs and de-emphasize use of the save button (everything is always saved at all times).

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

#114
post #109
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…

Can you share how these are aliased? I love git and only recently became more of a daily user of it in the command line.

probably just an alias in .bash_profile, here's the first thing I found in google: https://www.moncefbelyamani.com/create-aliases-in-bash-profi...

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

#115

Hmmm...rm -fr .git Now what?

Nothing protects against rm -rf by design. You shouldn't use it to blindly clean up and delete files (unless as a last resort or some very specific and careful use case). Just use plain old rm and feed it the explicit list of files to delete, which forces you to actually look at what you're about to do.

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

#116
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 use the local history in Jetbrains/IntelliJ/PyCharm all the time. Can use it on a current file, or even mark a folder if you accidentally deleted something. It annotates the checkpoints with metadata as well. Like "this is how the file looked when you ran a test that failed".

Local history saves my bacon about once a month. It's incredibly helpful as it lets me adopt a fearless refactoring approach knowing that I can always get back.

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

#117
post #108

Earlier quoted context omitted.

Fossil has had this feature for a long time

> Fossil has had this feature for a long time (A long-time fossil contributor here.) Fossil has no such feature. Fossil sync synchronizes the remote and local saved state (checked-in/saved state only ). It does not do anything with un-checked-in state. That said, you can use fossil's stash to periodically take a (non-sync'd) snapshot using something like 'fossil stash snapshot -m "snapshot @ $(date)"' (i have that al…

Goofy context here:

‘sgbeal and I were doing some fossil dev work ourselves (I’m personally not at his level of fossil-fu, but am a long-running user and contributor). Our work was in a fossil repo (he in Europe, me in North America) and we were using the chat[0] feature to discuss our work when we noticed and discussed the GP post. Fossil has been self-hosting for ages, now is it self-correcting? /s

[0] https://fossil-scm.org/home/doc/trunk/www/chat.md

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

#118
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…

Have you considered using `git commit --amend --no-edit` after making your first commit? It simplifies the unwinding step.

This is pretty much my workflow, too. I’ll make some changes, `git commit -m wip`, and then `g can`. When you’re ready to prepare the PR/diff, `reset HEAD^`. Then, a few cycles of `add -p`, `commit -v`.

`commit --amend` and `add --patch` are super powers!

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

#119
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 do something similar but a little more manual that your solution. I `git commit -am "WIP"` to save random, odd-ball intermediate working states. Occasionally the commits get real messages but I try not to let it interrupt the flow.

Then when I'm ready to commit or cut PRs, I just squash them all down if it's trivial. If it's a bigger change: I push things to a backup branch, `git branch Branch-BK`, reset to a base commit, and use difftools to pull over the subset of changes I want and commit them repeatedly until there's no diff left.

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

#120
post #109
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…

Can you share how these are aliased? I love git and only recently became more of a daily user of it in the command line.

Yup, check out my comment here: https://news.ycombinator.com/item?id=29786798

(I use just external scripts rather than git aliases because I find it a little nicer to work with; git has a feature where if you enter "git foo", it will look for a command "git-foo" to execute.)

Post reply on HN