Put another way - if you think about something similar with cleaner abstracts - we'll use an FS with O(1) snapshots (BtrFS, ZFS, etc) At the UI layer - to the

Put another way - if you think about something similar with cleaner abstracts - we'll use an FS with O(1) snapshots (BtrFS, ZFS, etc) At the UI layer - to the user they see a snapshot as a complete, exact copy of the filesystem for each snapshot. How this happens is an implementation detail. As far as the user is concerned the system is storing a complete, exact copy of the FS at each snapshot. At the FS layer, is a snapshot stored as a complete, exact copy of the filesystem? Absolutely not :) It is stored as a pointer to some root object most of the time. If you go further down, the objects may or may not be stored complete. They may be compressed. They may have portions of the object shared with other objects (dedupe and block cloning/sharing), etc. As you go further down the abstractions, at some point it's not an implementation detail but instead fairly fundamental to the system. In this case, as with git, the system could not afford to store complete exact copies of the FS, even if it had a way of doing so in O(1) time, which isn't possible in our universe anyway.