From 514bbfd7f3b14e733ae53abc35a7d505f7ee0447 Mon Sep 17 00:00:00 2001 From: paperbenni Date: Tue, 19 Oct 2021 16:45:12 +0000 Subject: [PATCH] --- doc/forum/git_annex_sync_destroys_data_on_shallow_clones.mdwn | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 doc/forum/git_annex_sync_destroys_data_on_shallow_clones.mdwn diff --git a/doc/forum/git_annex_sync_destroys_data_on_shallow_clones.mdwn b/doc/forum/git_annex_sync_destroys_data_on_shallow_clones.mdwn new file mode 100644 index 0000000000..1b88cd0a74 --- /dev/null +++ b/doc/forum/git_annex_sync_destroys_data_on_shallow_clones.mdwn @@ -0,0 +1,2 @@ +I just migrated binaries from native git file tracking to git annex. Then I went on to clone the repo on a different device. Because older commits still contain the binaries I did a shallow clone. After that I wanted to fetch a few binaries from annex and ran ```git annex init; git annex sync```. +To my surprise instead of somehow working out the annex metadata with the remote it just force pushed an empty git-annex branch to the remote. Luckily I was just testing things out and had a backup available but for people who rely on a service like gitlab to access their annex repository when traveling this can end up being a very nasty surprise. I don't exactly know how this could best be fixed but force pushing without asking isn't a good solution in my opinion. Maybe git-annex-init could check if a remote already has annex metadata and pull that. git-annex-sync could fail and give you the option to add a force flag or work out how to merge things (which shouldn't be too hard when the local metadata is completely empty) -- 2.30.2