New way track and group working tree changes in Git
New Git change-storage architecture: 3 snapshots, constraints, and smarter merging
Most Git tools represent changes as patches to replay later: a recipe of operations to perform.
This new architecture instead stores each logical change using three snapshots:
- the original file state
- the file after edits were made
- the version containing only the selected change
and stores rules for what lines/content should be present or absent: a set of constraints to illustrate the change.
When reapplying changes later, it doesn’t blindly replay a patch. It uses structural alignment of the file plus those rules to reconstruct the intended result. It finds stable unique anchor points in the code to match up where changes should be applied. In practice, that means repeated apply operations are idempotent, duplicate-line corruption is less likely, and it can behave better than a traditional 3-way merge on messy in-progress work.
Because changes are stored independently of the current diff, it can also survive continued edits to the working tree and be reconciled later.