Duy Nguyen <pclouds@xxxxxxxxx> writes: > - surprises sometimes, but in known classes. This is the main use > case of backup log, where I may accidentally do "git commit > -amsomething" after carefully preparing the index. Saving overwritten > files by merge/checkout could be done here as an alternative to > "garbage" attribute. The problem with either of these is not the "saving" half, but "restoring". For different people, and for different cases even to the same person, granularity of what is perceived as a single action is different, so "give me the state of my working tree files before the last operation" is a request that does not have a good definition. After finishing "git rebase" that replays 3 changes, one of which needs manual conflict resolution, you may realize that you made an incorrect resolution for one path but not others. How would you let the user say "no, I do not want to undo the whole rebase, I want to go back to the state where I replayed the first change, saw the conflicts while replaying the second change, and resolved them in these files, but before touching that last one I screwed up resolving, so that I can correct"? Piling many "backups" (or "snapshots") on top of each other is the easier part; I'd expect that it would be a much harder design problem to let users make use of them in meaningful ways, and that is the primary reason why I am skeptical.
