[HN Gopher] Dura is a background process that watches your Git r...
___________________________________________________________________
Dura is a background process that watches your Git repositories
Author : todsacerdoti
Score : 273 points
Date : 2022-01-03 18:25 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ttoinou wrote:
| Could we have this commit automatically ? so as to have a
| AutoGitFilesystem where our files modifications are always kept
| up to date on a server
| sahkopoyta wrote:
| 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
| masklinn wrote:
| > 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,
| ...).
| pcthrowaway wrote:
| 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.
| masklinn wrote:
| > 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.
| can16358p wrote:
| Not for you and me but might save hours/days of work for
| someone (including me-a-few-years-ago) who is lazy/forgetful
| about their commits.
| sahkopoyta wrote:
| "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.
| dbalatero wrote:
| Any unstaged work is getting committed in the background, so if
| you lose unstaged work accidentally, it will be available on
| that dura branch.
| agumonkey wrote:
| has anyone ever made the reverse of bisect, doing some kind of
| graph search over potential edits and let the thing grow and
| hopefully converge ?
| smm11 wrote:
| A newspaper reporter I knew in the early-90s did much the same
| with an external drive. Notes, then stories that came from the
| notes, were saved with a name-datetimestamp name, every time that
| person got up for some reason, or answered the phone, or felt
| like it.
|
| The 'master' file was the one on the local HD.
|
| That reporter was me.
| unbanned wrote:
| Hmmm...rm -fr .git
|
| Now what?
| remram wrote:
| 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).
| qbasic_forever wrote:
| 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.
| jdavis703 wrote:
| 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.
| ekiwi wrote:
| My biggest question after looking at the readme: What happens if
| your computer crashes while dura is making a commit? Can it
| corrupt your local git repository? From my own experience, git is
| not crash safe, i.e., it can leave the .git directory in an
| inconsistent state if the computer crashes during certain git
| operations.
| nine_k wrote:
| I wonder if the tool can be amended to commit to an independent
| git repo.
|
| Git can operate on two local repos reasonably efficiently,
| IIRC, so diffing and applying commits should be doable.
| howdydoo wrote:
| 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.
| voiper1 wrote:
| VS Code has a local history extension:
| https://marketplace.visualstudio.com/items?itemName=xyz.loca...
| dv_dt wrote:
| 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.
| plmpsu wrote:
| Is my understanding correct in that this serves the same function
| as Intellij's Local History?
| varsketiz wrote:
| Took me a while to realize this is derived from the word
| duraBILITY. At first I thought this was a russian word being
| used...
| ratww wrote:
| It seems the previous name of the app was "Duralumin" and they
| just shortened to "Dura".
| yosito wrote:
| The root is Latin, duro, which means hard.
| https://en.m.wiktionary.org/wiki/duro#Latin
| ljm wrote:
| I thought it was called dura (stupid) because 'git' is slang
| for idiot.
| abcd_f wrote:
| 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.
| mrestko wrote:
| And "git" is English slang for similar.
|
| Dura is also an anatomical term for the tissue encasing the
| brain.
| Koshkin wrote:
| Interesting. I've always thought it was the word from
| https://www.imdb.com/title/tt0095348/
| titanomachy wrote:
| It's also the name for the protective membrane that surrounds
| your brain!
| grishka wrote:
| 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.
| mynegation wrote:
| Also Spanish or Portuguese adjective in feminine form, meaning:
| "hard", "resistant", "harsh" etc.
| bregma wrote:
| 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".
| ajuc wrote:
| if you're a fool you will be happy you installed this tool
| dzdt wrote:
| I took it as short for "durable". But then again "git" is a
| common, slightly rude English word for "fool" or "imbecile" as
| usually applied to men...
| tkellogg wrote:
| 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.
| bobuk wrote:
| Perhaps you will find it interesting: in Russian, the
| abbreviated word "dural" is often used for duralumin.
| warent wrote:
| Off topic: great choice! I love all of Brandon Sanderson's
| works. Enjoy it, the first Mistborn series has a very
| satisfying conclusion!
| VTimofeenko wrote:
| 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.
| bobuk wrote:
| Sometimes the word "dura" has the meaning of "something big
| and an intricate nature," i.e., just a synonym for "stuff."
| For example, "polozhi etu duru v shkaf" (put this stuff in
| the closet)
| chmaynard wrote:
| 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.
| baby wrote:
| 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.
| pcthrowaway wrote:
| The docs say it only watches repos you tell it to
| procrastitron wrote:
| I built a similar tool a couple of years ago here:
| https://github.com/google/git-sync-changes
|
| Both save uncommitted changes in a hidden ref.
|
| Based on the README, the differences seem to be:
|
| 1. dura runs as a daemon while git-sync-changes is a one shot
| execution.
|
| 2. dura saves locally, while git-sync-changes syncs with a remote
| repo.
|
| 3. dura only does the save and the restore is manual, whereas
| git-sync-changes does both steps automatically.
|
| I'm glad to see more people exploring this space. I think there's
| a lot of untapped potential in tracking pending changes similarly
| to how we track committed changes.
| lucas_v wrote:
| Or you could just "git push" responsibly...
| swills wrote:
| Sounds neat. For me, local scheduled periodic file system
| snapshots serve a similar goal, and on a wider scale.
| specialp wrote:
| 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.
| sneak wrote:
| I keep my git repositories in a directory synced to other
| machines with syncthing. Those other machines keep a tiered
| version history of all synced files (not just git). One has zfs
| snapshots, as well.
| zffr wrote:
| This is cool, but for me to use it I would need a LOT of
| confidence that the tool wouldn't just silently stop working one
| day. With my luck that would probably be the one day I actually
| needed to use this tool.
|
| You may want to look at turning this into a systemd/launchd
| service so the OS can launch the tool on boot and handle
| restarting it on crashes.
| paxys wrote:
| 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.
| yosito wrote:
| 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.
| dbalatero wrote:
| 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!
| nathancahill wrote:
| I love Hammerspoon so much.
| tkellogg wrote:
| 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.
| sneak wrote:
| ssh root@remotehost 'apt install -y zfs-auto-snapshot'
| while sleep 1 ; do rsync -avP ~/Documents/
| user@remotehost:Documents/ ; done
| rubyist5eva wrote:
| Just use git rebase --autosquash
|
| https://thoughtbot.com/blog/autosquashing-git-commits
| w_t_payne wrote:
| I've also built a tool to support hyper-frequent commits,
| automatically rolling back the commit if the build, static
| analysis or any tests fail. This ensures a complete history of
| 'good/working' builds in the vcs.
|
| https://github.com/wtpayne/hiai/blob/master/a3_src/h70_inter...
| xixixao wrote:
| 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
| marcofatica wrote:
| Fossil has had this feature for a long time
| sgbeal wrote:
| > 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 aliased and
| use it often). That does _not_ enter the SCM history and _is_
| lost if you destroy the checkout dir.
| bch wrote:
| 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
| dradtke wrote:
| I'm curious about this, any links handy?
| klaussilveira wrote:
| https://fossil-scm.org/home/doc/trunk/www/sync.wiki
| [deleted]
| dilap wrote:
| 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?
| tomrod wrote:
| 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.
| dilap wrote:
| 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.)
| texuf wrote:
| 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...
| bastardoperator wrote:
| 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.
| whoomp12342 wrote:
| 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.
| Quekid5 wrote:
| 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.)
| elpakal wrote:
| 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.
| gregoryl wrote:
| 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!
| mbarneyme wrote:
| Do you have those commands handy by chance? :D
| jasonpeacock wrote:
| It's usually something like: git status &&
| git add -A git commit -m "checkpoint" --no-verify
|
| I include `git status` so I can see what's being committed.
| `--no-verify` is used to skip any pre-commit hooks.
| glenjamin wrote:
| You can use `-v` on the add to see what it's doing instead
| of the extra status
| dilap wrote:
| Sure thing https://gist.github.com/erinok/0247c134a57acdb2e2d
| aafdf1d77a...
|
| 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)
| gen220 wrote:
| 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!
| mlyle wrote:
| If you do this, and find you want to go back to 3-4 commits
| ago, you need to dig around in the reflog for it.
| merightnow wrote:
| 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.
| genuine_smiles wrote:
| I keep a draft PR open to keep track of this. Not has nice as
| vs-codes diff tool though.
| ianjsikes wrote:
| You can still use VS Code's diff if you have the GitHub
| Pull Requests extension: https://marketplace.visualstudio.c
| om/items?itemName=GitHub.v...
| rubyist5eva wrote:
| You can do this already with git natively.
|
| https://thoughtbot.com/blog/autosquashing-git-commits
| buscoquadnary wrote:
| 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.
| nicois wrote:
| 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.
|
| https://gist.github.com/nicois/e7f90dce7031993afd4677dfb7e84...
| Ransom_ wrote:
| 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
| DarylZero wrote:
| It seems like you could just use the index.
|
| I.e. just use "git add -A" instead of "git cam"
|
| Then you don't need "git wip"
| dilap wrote:
| For me, having it be a real commit is nicer -- can switch
| between branches, push if I'm switching computers, look at
| history, &c.
| kjeetgill wrote:
| 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.
| klysm wrote:
| Might be a useful workflow for you to use fixup commits to
| rebase automatically helps you out
| Vinnl wrote:
| 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.
| jwineinger wrote:
| 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.
| barbazoo wrote:
| 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.
| mlyle wrote:
| 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.
| pizza wrote:
| 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
| matsemann wrote:
| 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".
| pjerem wrote:
| 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
| sa46 wrote:
| 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.
| danslo wrote:
| I see no reason to use this if you commit often and know how to
| use reflog.
| thatswrong0 wrote:
| So then don't use it.
|
| I prefer not rebasing / editing unless I have to.
| dahart wrote:
| What do you mean? The concept of dura is editing. And using
| reflog isn't normally a rebase.
| saila wrote:
| 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.
| kadoban wrote:
| 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.
| mlvljr wrote:
| admax88qqq wrote:
| 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.
| fishtoaster wrote:
| 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!
| DarylZero wrote:
| 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.
| xcambar wrote:
| Proper text editors[0] do this since decades.
|
| [0]: vim and emacs, at least.
| sneak wrote:
| > _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.
| mkdirp wrote:
| IntelliJ does it, and you can even look at the local history
| and go back as far as you like.
| thebean11 wrote:
| 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.
| qbasic_forever wrote:
| 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).
| matu3ba wrote:
| I would prefer something less broken than google docs.
| Something which can track semantic file changes in projects.
| [deleted]
| vbezhenar wrote:
| 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.
| whartung wrote:
| 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.
| encryptluks2 wrote:
| You mean like a keylogger that saves everything to some third
| party?
| admax88qqq wrote:
| Yes clearly that's exactly what I meant...
| felixr wrote:
| 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
|
| [0]: https://vimhelp.org/undo.txt.html#undo-tree [1]:
| https://github.com/mbbill/undotree
| kuon wrote:
| I use ZFS, and on my home directory I have ZFS snapshot every
| minute for the last hour and every hour for the last 24h. It
| saved me so many time.
| Eun wrote:
| Running with the same setup. It's a perfect solution.
| clircle wrote:
| Emacs's autosave is quite excellent at recovering my work when my
| computer crashes. M-x recover-this-file
|
| https://www.emacswiki.org/emacs/AutoSave
| mssdvd wrote:
| magit has a mode, magit-wip-mode, that can do what dura does
| (but it only works if you make changes with Emacs).
|
| https://magit.vc/manual/magit/Wip-Modes.html
| dahart wrote:
| 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?
| jhardy54 wrote:
| Reflog is a log of refs. If you don't make commits then then
| nothing is added to the ref log.
| dahart wrote:
| 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.
| jdavis703 wrote:
| 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.
| weaksauce wrote:
| 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.
| dahart wrote:
| > 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.
| [deleted]
| avgcorrection wrote:
| I don't understand these backup tools which masquerade as VCS
| extensions.
|
| I want my VCS commits to be intentional. If they're not then I'm
| just using a fancy VCS tool[1] for backup--just set up a _dumb_
| backup routine that backs up every X interval and doesn't have to
| care about the intentionality behind any changes made (the domain
| of version control).
|
| And if you get into a situation where you haven't committed for
| such a time while that you risk losing "days of work" then...
| seriously? You might want to get a better Git client where
| committing isn't such a pain (IMO the CLI is too much typing for
| git(1). Magit is great).
|
| And as already mentioned there is the reflog. Which is difficult
| enough for me to navigate sometimes without some pseudo-backup
| tool making a mess (on top of _my_ mess...).
|
| [1] Git might be "stupid" but it's also quite fancy.
| stavros wrote:
| > If they're not then I'm just using a fancy VCS tool[1] for
| backup
|
| Yes you are; what's wrong with that?
| mgirdley wrote:
| You might have a trademark problem coming your way...
|
| http://dura.software
| ViViDboarder wrote:
| Maybe a frivolous one. They don't have a product named Dura not
| anything that looks remotely similar.
| lowbloodsugar wrote:
| 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.
| endisneigh wrote:
| Is there a built-in way to configure Git to just make a temporary
| branch and commit every file save?
___________________________________________________________________
(page generated 2022-01-03 23:00 UTC)