Directory sync now skips files under a git content filter and tells you the reason.
What's wrong with this entry?
Syncing a directory now consults git check-attr to see whether each file sits under a git content filter, and leaves those files behind rather than copying them. Skipped files are reported with the reason content_filter, or attributes_unreadable when the file's git attributes cannot be read at all, which is handled the same way as the other outcomes where the attribute store cannot be consulted. Failure reporting and pull statistics were extended to match, so a sync now says more precisely what it did and why.
- The content filter check runs at both stages of a sync: the initial file inventory and the pull step that fetches file contents.
- Sync failures now distinguish
version_unsupported, meaning the git version in use cannot do the check, andabortedfrom a plain timeout, so a stalled sync is no longer conflated with an unsupported or cancelled one. - Retries after a failure can now back off exponentially rather than retrying at a fixed interval.
- Pull statistics gained counters for content-filtered files, for copies that were kept, and for replacements made without keeping a copy.
- Apply results additionally report replaced and removed counts, the overlay status and head, and a reason when the file manifest is rejected.
content_filter, version_unsupported
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
Sync state machine gains a moved-root case and a per-turn pull hook
Both mention directory
-
v2.1.238
Untracked-file survey extracted and shared
Both mention directory
-
v2.1.238
Sync internals reshaped around per-file credential state
Both mention directory