3 ms·

> You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a

> You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess). Google does this, it has saved my butt on more than one occasion. > Sounds like saying bye-bye to any meaningful history. I'm so confused, you just amend the most recent commit, or work with changes unstaged and uncommited. Like my normal workflow is basically "change 2-3 files such that things are passing, hg commit, send for review", and then I continue working on the next thing, either back to HEAD if its unrelated, or on top of the just-pushed changes if it depends on them. It's vastly simpler than having to git add at random times.

still_grokking 4y ago
> > You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess). > Google does this, it has saved my butt on more than one occasion. You mean backups? Yes, backups are a very good idea. But this has nothing to do with VCS. That are separate topics. > Like my normal workflow is basically "change 2-3 files such that things are passing, hg commit, send for review", and then I continue working As long as the requirements are so trivial even CVS would suffice. But even considerably simple refactorings (in e.g. static languages) can be much more complex. It's easy to end up with hundreds of files changed. Than you need more powerful tools. Doing such things without the staging area is almost impossible to get right. (The only alternative would be quite some rebase sessions; and those are way more complicated than using the staging area upfront; also you would need some way to do diffs against "pined" changes—which is something you get for free with the staging area).
- joshuamorton 4y ago
  > 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. via https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext 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.

still_grokking 4y ago

> > You could just publish local IDE history… Would be equally "good" I think. (My IDE is saving files every few key strokes btw; the resulting history would be a bloody mess). > Google does this, it has saved my butt on more than one occasion. You mean backups? Yes, backups are a very good idea. But this has nothing to do with VCS. That are separate topics. > Like my normal workflow is basically "change 2-3 files such that things are passing, hg commit, send for review", and then I continue working As long as the requirements are so trivial even CVS would suffice. But even considerably simple refactorings (in e.g. static languages) can be much more complex. It's easy to end up with hundreds of files changed. Than you need more powerful tools. Doing such things without the staging area is almost impossible to get right. (The only alternative would be quite some rebase sessions; and those are way more complicated than using the staging area upfront; also you would need some way to do diffs against "pined" changes—which is something you get for free with the staging area).

joshuamorton 4y ago
> 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. via https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext 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.