Comments in the moderation queue:
Recent comments posted to this site:
With the proxy command, would the following be an appropriate way to discard all changes (mods, adds, dels) since last sync in a direct mode repo?
git annex proxy -- git clean -df
git annex proxy -- git checkout -f .
Also, is it necessary to run annex sync or other direct mode housekeeping commands afterwards?
therefore instead of tagging the files and placing them into subdirectories (which somehow seems confounding views reperesentation), i'll be using sparse checkout for the subdirectories I need.
i'll be looking in sparse checkouts so that i have separate trees checked out from same annex ( see http://git-annex.branchable.com/forum/sparse_git_checkouts_with_annex/ )
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 merge in a removable repo after pushing to it (but git annex sync should 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.
git annex merge
git annex sync
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.
I have an image 'logo.jpg' that is 100kb. I am using indirect mode.
I add the logo to the annex; my understanding is that the file contents is stored in .git/annex/....
I do more work in Photoshop to improve logo.jpg. Now, I have a new version of 'logo.jpg' that is 150kb.
I add this new version of logo.jpg to the annex.
Does the .git/annex area now contain two instances of the logo.jpg contents, one for the 100kb and one for the 150kb, with metadata pointing to each?
I tried to solve this use case with a post-receive hook and had to realize that FAT does not support the executable bit and thus the hook doesn't run. I've found several requests for the use case described here and I think it would be desirable, if the assistant/webapp could solve it without commandline-hacks.
So I want to stick my thumbdrive in my work desktop and the assistant notices that it's available and starts copying stuff on it and runs git annex merge afterwards.
I also had to manually set annex.diskreserve to a smaller value since annex wants to reserve more space (10G) than is available on most thumb drives. I think git-annex init should be more clever about the default diskreserve value, e.g. set it to a percentage of the total disk size.
I think you need at least one server that is reachable from every device and serves as a transfer repository. XMPP is only needed to inform peers about changes. Usual the assistant performs a startup check and detects changes that way. You can't sync content over XMPP.
All that is very afaik, I hope for corrections if wrong.