Snapshot restore now catches file permission changes, so an executable bit flip isn't missed.
What's wrong with this entry?
When a workspace snapshot holds files at their committed state, it now records each path's file mode alongside its content id and fails the snapshot if either differs from what the commit holds. An executable-bit change can no longer pass as an unchanged file.
- The check reads git's staged file listing including mode, and the mismatch is reported with the existing wording
are not the ones HEAD holds. - Not gated; runs as part of the normal snapshot path.
are not the ones HEAD holds
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.238
Bridge-spawned sessions start with credentials stripped from their environment
Both mention snapshot