story: i got a new drive from the store. plug it in. it's recognized by XFCE and mounted automatically. turns out it's NTFS, but Debian doesn't seem to mind.
go in the assistant, add it as an "External drive", make it a "full backup" and let it sync.
expected result: i see files
actual result: i see a bare git repository.
if i first git init the directory so it's not bare, at least i get a better handle on it: i can sync with the assistant, then git merge synced/master to see the files.
really confusing to me, sorry if it's a dupe...
workaround: use the commandline: git clone <repo> and git annex get. --anarcat
I started to make this change, and then I realized this problem: If a non-bare repository is made on an external drive, then to the user this is another place they can edit their files. Which means they will expect their changes made there to be committed. Which is highly problematic, because the assistant cannot be left running on an external drive or it won't be able to be unmounted. Or, a periodic
git annex add; git annex synccould be run on the external drive, but that is a more expensive process (especially when run on a slow drive) and would not meet the expectations of users of the assistant that their changes will promptly propagate.So, I feel that leaving bare repositories is actually the best choice.
i wouldn't expect those changes to be committed. it's an external drive, and unless i manually sync it, it should take into account my changes.
i am more surprised by the bare repository than i would be surprised by my changes not propagating back, i think. --anarcat
Of course you wouldn't expect that, I've explained the problem to you and you're technically adept and know about issues with keeping open files on removable drives.
However, I have to consider the affordances of what the assistant sets up, and the natural affordance of a drive containing a directory with your files in it is to be able edit those files. And when changes in every other clone of that directory get automatically synced, the expectation would be for the same to hold true on this directory on the removable drive.
I can see perhaps having the assistant run
git annex mergein a removable repo after pushing to it (butgit annex syncshould not do that; violates least surprise for a git pull+merge+push wrapper like that to affect the work trees of other repos). As long as the assistant defaults to making removable repos bare, it won't expose normal users to the problem, and only advanced users who know how to set up non-bare repos.If this is only for advanced users though, it (both assistant and
git annex sync) could just as well run a configurable command on a removable repo after pushing to it. Or, the advanced user could use their skillz to make the removable drive be formatted with a reasonable filesystem that allows executable files, and then set up a git post-receive hook.It's now pretty easy to set up a remote on a USB drive so that
git annex syncwill update the work tree. See https://git-annex.branchable.com/tips/making_a_remote_repo_update_when_changes_are_pushed_to_it/However, the assistant does not do this by default when adding repos on USB drives, due to the likely confusion that setting up such a repo would cause, as described in my previous comment.