When an exporttree=yes remote has had a tree exported to it, but eg with
git-annex export master --to foo --fast, so not all the files have been
sent to it yet, git-annex sync -Cfoo will also export files in other
directories to it.
This seems like a bug, it ought to only export any files in the specified directory.
Another way this can happen is git-annex sync -Cfoo, when file bar
has changed. Currently this exports bar to the export remote, but does
not send it to any other remotes, since it's not in directory foo.
Also this affects git-annex satisfy, and other related commands too.
--Joey
Decided to just document this behavior since there does not seem to be any good alternative behavior. done --Joey
If files foo and bar have changed, and
git-annex sync -Cfoocommitted those changes and only exported foo to an exporttree remote, then that remote would end up with content that does not correspond to any git tree that the user has constructed.While it's possible for that to also happen when an export of a tree gets interrupted in the middle, git-annex recovers from that when the export is re-run. But here the user might have a workflow where they are only running that command.
So this would be a new case, and to handle this case it seems it would have to dummy up a tree representing the changed foo and old bar, in order to record the export in the git-annex branch and sync it so other repos know what the content of the export remote is.
So doing that is not feeling like an entirely good idea..
I suppose the alternative would be for
git-annex sync -Cto not send anything to export remotes. But that also seems potentially confusing. (Especially as a behavior change.) If I've asked git-annex to sync with an exporttree remote, shouldn't it do it? Even if it has to do some additional transferring in the process.So it may be that the current behavior of sending additional files is better.