"including me-a-few-years-ago". This also applies to me, sometimes you have to learn the hard way. I would say that in this scenario addressing the root cause is better than treating the symptoms.
> 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.
> 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 definitely wished IntelliJ's local history could work across multiple files a few times, it did let me recover from fuckups more than once but having to find and revert each file individually was not fun.
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 love this. One of the biggest reasons people don't frequently commit their code is fear of "polluting" their feature branch. Automatically creating and pushing to backup branches is the best of both worlds.
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.
Yes! I'm the author and this is the next feature I was planning on adding, I was even planning on naming it `dura status`. First I need to get better logging (to a JSON file), and then expose it via `dura status`. It occurs to me that having all that data could tell me a lot about how I work, so it could unlock some very interesting usages of dura.
Would you mind creating a Github issue? The project could benefit from more discussion around this.
I’ve had this idea for about 10 years - it really pays off to wait and eventually someone will build all my ideas :)
There are many things to build on top:
- Squash history so that it doesn’t grow indefinitely.
- Be somewhat language aware to provide better commit messages
- IDE integration
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 aliased and use it often). That does not enter the SCM history and is lost if you destroy the checkout dir.
‘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
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 command "git cam" that just commits all changes with the message "nt". Then once I'm ready to do a "real commit", I have "git wip" which rolls back all the nt commits but leaves them in checkout; then I can make one or two "real" commits.)
I wonder if dura would be even better, or if the commit frequency would end up being too fine-grained and obscure?
Yep, exactly. My terminal autocompletes to previous commands, so it's pretty easy to get to 'git commit --fixup HEAD', likewise for a rebase with --autosquash.
It's a handful of commands because git-cam and git-wip referenced other little utility scripts, so hopefully I got them all. Probably it would be easy to rewrite to be standalone.
I'm on a mac, and I have ripgrep installed as "rg". Ymmv, glhf :-)
So:
"git cam" commits everything with message "nt"
"git wip" undoes all the nt commits but leaves the results staged, ready to be commited as a single properly worded commit (or play w/ what's staged and do as several commits)
I've tried that as well. For me it was really difficult as I use the current changes quite a lot, and it makes it a lot more difficult to grasp the work I've done so far without having a meaningful change set.
you can use separate dev/release branches, and do something like "git diff master" (if you dont git push, you don't even need a separate branch, git diff origin/master works, but you lose half the point of frequent commits then)
This workflow sounds similar to the one we use at my company! I use the git-ps tool we made to make stacks of usable micro-commits, and using the tool to keep things logical and working as things change and the code develops. https://github.com/uptech/git-ps
I do something similar, but with larger intermediate commits than yours and more meaningful messages. Then at the end, I do an interactive rebase, squash the ones I don't care about, and reword the final commit message based on the hints I left myself in the squashed ones.
I do a combination of the two: the first commit gets a meaningful (but still draft) message, and their follow-ups are all committed with "." as a message - but only until "switching gears", i.e. until a commit comes that is logically separate from the bunch before it. Those commits that have messages then provide logical milestones for squashing.
This breaks down sometimes if you have to switch back and forth between different parts of code, breaking the linear sequence. But even then, the messages make it easier to connect the pieces when it's time to clean up history before the pull request.
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.
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.)
I don't mean 60s literally. I mean arbitrarily small commits at your own convenience.
You don't need to have even remotely working code when you commit, is the point. You just commit whenever. (It's almost like saving files, just commit.)
I think the word 'commit' might have been a mistake, now that I think about it. Maybe 'snapshot' would have been better.
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 <target>` 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 branches and don't really rely on commit history auditing during review. I understand that's not the case everywhere, but works for me.
I just gave this workflow a shot and it was great. Thanks for the tip! Do you use anything for committing more granular chunks of code? I'm just committing groups of files but after reading about magit on other hn threads, I feel like I could do better.
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.
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".
Clearly, my JetBrains IDEs paid themselves multiple times by saving me from « oh shit » situations. Best investment my employer did without never knowing it :D
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.
I think what you're doing is better because it's more explicit. I feel like Dura is yet another tool for people that don't know, and don't want to learn, Git.
Eh. I do tens of commits and then squash into 1 or a few, sometimes by resetting back and a few add --patch and sometimes by interactive rebasing.
But I can see times where Dura could be kind of nice. When I'm doing CAD or other not-very-source-code things, having a few snapshots be grabbed along the way sounds nice. Going to try and git commit in intermediate states feels a little too mode-switchy to me.
I would like to go this approach. I simply forget to commit until I’ve wrapped up something big, but I’d like to submit more frequently so others can see my work. Is there something that will remind me to commit? Esp. In VSCode
(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.)
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!
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.
This is also my pattern. To further assist with this, I wrote a short(ish) rebase script intended to be run when you want to squash your series of commits, also bringing your local branch up-to-date with the upstream. It relies on your initial commit in your feature branch having a commit message which corresponds to the branch name, but that's it. This does a great job of minimising unnecessary merge conflicts, even after working offline for an extended period.
> 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.
Aren't you describing a feature branch? That frankly sounds like git 101.
Nope. A feature branch is still expected to have meaningful commits, and is usually used for collaboration between several coders. Its history doesn't get rewritten.
What OP describes is a temporary work branch that belongs to a single person, and has a bunch of meaningless commits. So nobody else should be using it - or if they do, they need to sync with the owner, since the latter can squash or otherwise mutate commits at any time.
I have a `git snap` command that's similar to your `git cam` command with a small twist. The commit is added to a special snapshots branch that isn't checked out. I push the snapshots branch and don't rewrite it, but rather keep it around as an accurate chronological record of things I've tried, warts and all. I also like that `git diff` continues to show the changes compared to the last "real" commit this way.
Edit: I guess my script is somewhere between your `git cam` command and Dura in terms of functionality and complexity.
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.
Well, it's funny because the Apple stuff works like this, but not Xcode.
I pretty much never save anything with Page/Numbers/TextEdit. I just quit
Not only do I not lose changes, I don't lose editions. I can go back to older versions. And that's not including Time Machine. It's simply "built in".
From a user experience, it's really wonderful and no stress. I don't even think about it. At the same time, I have no idea where these extra versions are stored but, honestly, I don't care.
I do wish other applications worked similarly. Source code is tricky, but it probably wouldn't be awful to have a similar experience.
A lightweight way to accomplish this is to at least set up frequent autosaves in your editor. I had `au FocusLost * :wa` in vim to save all buffers to disk whenever it loses focus. Now that I've converted to the church of VS Code (with vim bindings, of course), there's an "Auto Save: onFocusChange" config option to do the same thing. I don't know how people live without it!
You don't always want to save to disk though, you want to save in a consistent state. Vim allows you to set up a persistent undo that will let you load the modified buffer from a backup file without touching the original until you're ready. Or undo back to the saved on disk version. Or undo even further to previous versions. That's true persistence.
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.
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.
vim had an undo tree for 10 years (or longer?) [0] and there are plugins (eg [1]) that make it very easy to go back in history and also to explore different branches of your undo/edit history. Dura will not track changes that are not saved to disk IIUC
> 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.
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).
Git has a built-in Ctrl-Z that is called “reflog”. Acknowledging that git’s UI commands such as “reflog” may be technical, and nonstandard, and poorly named, does dura provide something that git doesn’t, and is it a good idea to add yet another application/layer/dependency to the git workflow? Would it be just as effective to add a git alias called “undo”, or something like that?
True, fair. I was about to delete my somewhat dumb question. Yeah I guess if someone’s not saving early & often, this could definitely catch some mistakes.
It’s not dumb, I had the same question. Would’ve been great if the value proposition explained how it was different than using the reflog.
In my experience there’s a lot of Git tools out there that basically exist because people don’t want to read the manual. But seems like Dura is not one of those.
that's tangential to this tool though. the reflog is for any git changes. this is a tool that checks for changes every 5 seconds or so and commits them to a shadow branch. there are a few things that standard git will clobber too without any recourse from the reflog.
> there are a few things that standard git will clobber too without any recourse from the reflog.
True! Stash is one of those things, right? Does dura catch the stashes specifically? Clearly it’ll catch whatever work you did before stashing, but if it saved stashes specifically in it’s own thing, that would be extra handy.
IntelliJ (and I assume other JetBrains IDEs) track local changes as if they were commits - you can diff history for example. I've seen it lose changes across a crash though, so something running on disk would be very nice.
I use Time Machine on an external drive. I learned this lesson the hard way… Obviously it’s not perfect, but you aren’t going to lose an entire days work.
This has happened to me unfortunately and didn't feel good at all. I ran `rclone sync` on the folder that had .git instead of the correct subdirectory, and that removed files not present in the source with confirmation (like rsync --delete-after). I've learned to commit and push to a remote frequently (which is easy with Git because you can use any machine you can SSH).
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.
This feature is built-in to all the JetBrains IDEs. Right-click your project, open Local History, and you can diff any file at any two points in time. That's saved my bacon more than once.
It might be simpler for dura to stage your work every 5 seconds (git add -A) without creating a new commit each time. Not sure how git handles many small changes in the index.
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.
JetBrains "local history" for InteliJ IDEs has saved me several times. It has all of the diffing tools that are available for git commits. This looks to be a generic implementation of that. We should not live in a world where unsaved data is lost.
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 IDE's local history to get back to a good place if I need it.
I wonder if it would be good to combine these ideas: commit and automatically push every N minutes. Is this something that's being considered for Dura? Or is it a bad idea?
One big challenge must be avoiding commits when someone's right in the middle of typing, although having to stitch a couple adjacent commits together would definitely be better than losing work.
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 software, wiring it into git doesn't seem to add anything.
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.
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.
Not to mention Latin. The French equivalent is "dur[e]". The membrane surrounding the brain is "dura mater" to an anatomist, which is Latin for "hard mother".
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 name, so there's no chance anyone else will. Plus is has that "durable" vibe to it, which seemed appropriate.
As a Russian speaker, I would say that I feel our swear words become truly offensive when they are explicitly targeted at a person. "Dura" is also not considered to be an expletive, and I have not heard it being used in its original meaning after I finished 5th grade. Pronunciation in Russian is also different, word sounds like "doo-ra".
FWIW the same word "dura" may also be used as a slang word for a large and unwieldy inanimate object.
Sometimes the word "dura" has the meaning of "something big and an intricate nature," i.e., just a synonym for "stuff." For example, "положи эту дуру в шкаф" (put this stuff in the closet)
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 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.
It's pretty hard to name something without having it accidentally stand out in one of thousands of languages (or even a few major ones). I wouldn't read too much into the intention.
206 comments
[ 3.8 ms ] story [ 145 ms ] threadThat 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, ...).
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.
I've definitely wished IntelliJ's local history could work across multiple files a few times, it did let me recover from fuckups more than once but having to find and revert each file individually was not fun.
watchexec -c -e go 'go test ./... && git commit -am "Tests pass"'
Would you mind creating a Github issue? The project could benefit from more discussion around this.
There are many things to build on top: - Squash history so that it doesn’t grow indefinitely. - Be somewhat language aware to provide better commit messages - IDE integration
(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 aliased and use it often). That does not enter the SCM history and is lost if you destroy the checkout dir.
‘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
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 command "git cam" that just commits all changes with the message "nt". Then once I'm ready to do a "real commit", I have "git wip" which rolls back all the nt commits but leaves them in checkout; then I can make one or two "real" commits.)
I wonder if dura would be even better, or if the commit frequency would end up being too fine-grained and obscure?
It's a handful of commands because git-cam and git-wip referenced other little utility scripts, so hopefully I got them all. Probably it would be easy to rewrite to be standalone.
I'm on a mac, and I have ripgrep installed as "rg". Ymmv, glhf :-)
So:
"git cam" commits everything with message "nt"
"git wip" undoes all the nt commits but leaves the results staged, ready to be commited as a single properly worded commit (or play w/ what's staged and do as several commits)
This breaks down sometimes if you have to switch back and forth between different parts of code, breaking the linear sequence. But even then, the messages make it easier to connect the pieces when it's time to clean up history before the pull request.
also, sometimes I just lump the whole thing into a PR because there arent more than one logical unit.
(... 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.)
I also don’t use an IDE.
You don't need to have even remotely working code when you commit, is the point. You just commit whenever. (It's almost like saving files, just commit.)
I think the word 'commit' might have been a mistake, now that I think about it. Maybe 'snapshot' would have been better.
This works well for my workflow because we squash all commits into target branches and don't really rely on commit history auditing during review. I understand that's not the case everywhere, but works for me.
edit: added question
I.e. just use "git add -A" instead of "git cam"
Then you don't need "git wip"
It annotates the checkpoints with metadata as well. Like "this is how the file looked when you ran a test that failed".
Repo here: https://github.com/zabel-xyz/local-history
Doesn't appear to mark checkpoints with metadata, though (test failed/passed, etc.).
But I can see times where Dura could be kind of nice. When I'm doing CAD or other not-very-source-code things, having a few snapshots be grabbed along the way sounds nice. Going to try and git commit in intermediate states feels a little too mode-switchy to me.
(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.)
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!
I must avoid those situations by making a new commit when I anticipate wanting to keep the reference to that point in work accessible.
I do dive into `reflog` maybe once or twice a quarter, but as far as I can remember, I only go there as an immediate reaction to tired-brain mistakes.
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.
https://thoughtbot.com/blog/autosquashing-git-commits
https://gist.github.com/nicois/e7f90dce7031993afd4677dfb7e84...
Aren't you describing a feature branch? That frankly sounds like git 101.
What OP describes is a temporary work branch that belongs to a single person, and has a bunch of meaningless commits. So nobody else should be using it - or if they do, they need to sync with the owner, since the latter can squash or otherwise mutate commits at any time.
No, not really. In fact, some issue tracking software equate feature branches with tickets, worked on by a single person.
> What OP describes is a temporary work branch that belongs to a single person, and has a bunch of meaningless commits.
Aka a feature branch.
Edit: I guess my script is somewhere between your `git cam` command and Dura in terms of functionality and complexity.
I prefer not rebasing / editing unless I have to.
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.
I pretty much never save anything with Page/Numbers/TextEdit. I just quit
Not only do I not lose changes, I don't lose editions. I can go back to older versions. And that's not including Time Machine. It's simply "built in".
From a user experience, it's really wonderful and no stress. I don't even think about it. At the same time, I have no idea where these extra versions are stored but, honestly, I don't care.
I do wish other applications worked similarly. Source code is tricky, but it probably wouldn't be awful to have a similar experience.
[0]: vim and emacs, at least.
"When Ctrl-Z is not enough"
As a french, I can only call this service Patricia. Because Patricia Kaas of course.
[0]: https://vimhelp.org/undo.txt.html#undo-tree [1]: https://github.com/mbbill/undotree
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.
https://magit.vc/manual/magit/Wip-Modes.html
In my experience there’s a lot of Git tools out there that basically exist because people don’t want to read the manual. But seems like Dura is not one of those.
True! Stash is one of those things, right? Does dura catch the stashes specifically? Clearly it’ll catch whatever work you did before stashing, but if it saved stashes specifically in it’s own thing, that would be extra handy.
Now what?
You mean, other than backups? Including editor backups, in a separate directory.
I use VSCode and if my computer crashes it'll just recover the unsaved files automatically. That's useful.
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 IDE's local history to get back to a good place if I need it.
I wonder if it would be good to combine these ideas: commit and automatically push every N minutes. Is this something that's being considered for Dura? Or is it a bad idea?
One big challenge must be avoiding commits when someone's right in the middle of typing, although having to stitch a couple adjacent commits together would definitely be better than losing work.
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 software, wiring it into git doesn't seem to add anything.
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.
Perhaps it was intended, but I can’t quite make a connection.
Dura is also an anatomical term for the tissue encasing the brain.
Apparently it left quite an impression on early anatomists/neurosurgeons.
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 name, so there's no chance anyone else will. Plus is has that "durable" vibe to it, which seemed appropriate.
FWIW the same word "dura" may also be used as a slang word for a large and unwieldy inanimate object.
I’d just never heard of it before.