{"version":"2.1.281","anchor":"cloud-git-sync-container-written-link-commits-can-be-receiv","canonical_anchor":"cloud-git-sync-container-written-link-commits-can-be-receiv","heading":"Cloud git sync: container-written link commits can be received","tier":null,"area":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/cloud-git-sync-container-written-link-commits-can-be-receiv","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Cloud git sync: container-written link commits can be received\n\nCloud git sync can now receive link commits written by the cloud container, with extra cleanup, logging and a clearer refusal message\n\n**Unclear.** The finding does not say what sets `peerWritesLinks` or when the container writes link bundles.\n\n**What**\n\nCloud sessions copy your project between your machine and a remote container (an isolated machine running the session) using git, the version-control tool. This sync gained a way to receive link bundles, packages of commits, that the container itself wrote. Other changes came with it:\n\n- Received links are stored under a `receiving` namespace as `in\/<generation>` refs, checked for a two-parent shape, then moved into place.\n\n- When `peerWritesLinks` is set, the sync prefers these received links as its starting point (its basis).\n\n- The seed start commit no longer counts as a basis.\n\n- The side repository, a separate git copy used for syncing, now deletes stray `index` and `sharedindex` files.\n\n- A new worker-init log line reports `claude_code_version`, `warm_spare` and a summary of tools.\n\n- A refusal caused by `.git\/info\/attributes` now explains that filter or macro rules are the problem.\n\n**Why**\n\nChanges made on the container side can now flow back through git sync. If sync refuses because of `.git\/info\/attributes`, the message now points at the filter or macro rules in that file."}