{"version":"2.1.282","anchor":"file-sync-refuses-repositories-with-tampered-git-objects-or","canonical_anchor":"file-sync-refuses-repositories-with-tampered-git-objects-or","heading":"File sync now refuses projects with damaged or outdated git history","tier":"notice","area":"File Sync","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282\/e\/file-sync-refuses-repositories-with-tampered-git-objects-or","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282","markdown":"### File sync now refuses projects with damaged or outdated git history\n\nCloud session file sync now checks a project's git data and refuses, with an explanation, when objects are tampered or trees use an old format\n\n**Unclear.** The size limits for the combined `.gitignore` files are not known.\n\n**What**\n\nFile sync, which copies a project into a cloud session, now checks the project's git data (the `.git` folder holding its history) before going ahead. It refuses and explains why when:\n\n- an item stored in git does not match the name it is filed under, which git itself never produces\n\n- the history holds a folder listing in an old format that git can read but does not write\n\n- it cannot create its own private working folder\n\n- the `.gitignore` files in the folder's subfolders together hold more than sync will read\n\nThe messages point to `git fsck`, git's own checking tool, to find the item at fault. Before, the only such check was for planted links.\n\n**Why**\n\nWhen a cloud session will not start because of the project's git data, you now get a message saying what is wrong instead of a refusal you cannot diagnose.\n\n- Area: File Sync\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}