> You mean backups? Yes, backups are a very good idea.
No, I mean that the filesystem I edit code in has a full snapshotted history of every save and I can recover to a particular revision or particular point in time, even one's that weren't committed to vcs[0]. I guess you can call that a "backup", but like it's not what people usually mean.
I have used this to recover some things I was working on three months ago but ended up throwing away.
(citation:
> All writes to files are stored as snapshots in CitC, making it possible to recover previous stages of work as needed. Snapshots may be explicitly named, restored, or tagged for review.
> It's easy to end up with hundreds of files changed.
Sure, doing a rename can touch 100 files, but you should isolate that change to a commit and PR that don't do anything else. Running sed and then committing or using your IDE's refactor feature, and then committing and running tests doesn't require a staging area.
[0]: The truly wild thing about this is that the vcs state is also stored in the snapshotted, point in time recoverable fs, so if you do the equivalent of absolutely botching your git history, you can jump back in time a few minutes and start from a known good state.
No, I mean that the filesystem I edit code in has a full snapshotted history of every save and I can recover to a particular revision or particular point in time, even one's that weren't committed to vcs[0]. I guess you can call that a "backup", but like it's not what people usually mean.
I have used this to recover some things I was working on three months ago but ended up throwing away.
(citation:
> All writes to files are stored as snapshots in CitC, making it possible to recover previous stages of work as needed. Snapshots may be explicitly named, restored, or tagged for review.
via https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...)
> It's easy to end up with hundreds of files changed.
Sure, doing a rename can touch 100 files, but you should isolate that change to a commit and PR that don't do anything else. Running sed and then committing or using your IDE's refactor feature, and then committing and running tests doesn't require a staging area.
[0]: The truly wild thing about this is that the vcs state is also stored in the snapshotted, point in time recoverable fs, so if you do the equivalent of absolutely botching your git history, you can jump back in time a few minutes and start from a known good state.