***** summary
if I run sync, and there is an annex-less git remote in the network
the annex-less git repo will gain a v5 annex branch
it knows it can't store binary files
but all the properly initialized annex repos in the network don't know that
when I run "sync --content",
the initialized annex repos think that the uninitialized repo contains copies.
I suspect this results in inaccurate "copies" count
I know it results in an inaccurate "list files' location" graph
and also inaccurate "whereis" readout
***** reproduction
repo "Alpha" is a git-annex repo with file "music"
repo "Zeta" is a git repo cloned from Alpha
@Alpha:
git annex sync --content
git annex list
[shows music present on Zeta]
git annex whereis
[shows music present on Zeta]
@Zeta
git annex list
[shows nothing]
git annex whereis
[shows music present on Zeta]
***** proving that the problem is "sync --content"
Hypothesis:
maybe the issue is that I cloned the repo
rather than creating it normally,
thus leaving it in a half-annexed state?
Experiment:
tested by creating an independent git repo
and then adding it as a remote to Alpha.
then ran sync --content
Result:
no different than before.
Conclusion:
The problem lies with
git-annex sync --content
***** ramifications
It would appear this error can cause data loss
due to a false numcopies count.
Yet GitHub is supposed to work.
So this error should've already been noticed.
Contradiction detected.
Positivity: I am planning on becoming a git-annex evangelist as part of a larger project.
Emacs offers ergonomic control via magit and a dired plugin.
***** environment
git-annex version: 6.20170301-ga9e1e17d40
build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
local repository version: unknown
supported repository versions: 3 5 6
upgrade supported from repository versions: 0 1 2 3 4 5
operating system: linux x86_64
done appears to be a confused user, not a bug. --Joey
When I wrote the above, I was unaware of the annex-ignore flag which can avert the above issue.
This flag should've been automatically set.
Also, I learned about the need for git-annex shell which must be available at the default path of remote servers.
This bug report is, to the best of my knowledge, totally wrong.
Yes, git-annex sync pushes the git-annex branch to all git remotes. This is intentional, and not a problem. That is just a git branch. It's helpful to push it to eg, github, if you want to be able to pull it from there into another clone. Pushing the git-annex branch to github does not make git-annex think that github is holding the contents of annexed files.
In your "reproduction" section, I think you forgot to run
git annex syncin Zeta, so its working tree had not been updated with the files synced to it from Alpha, which is whygit annex listdidn't show anything. Or somethig like that. You did not provide quite enough information to guess what you were doing.I'm going to close this. If you think it is still a problem, please provide either a detailed transcript demontrating the problem or enough information to reporoduce the problem, starting with an empty directory and constructing the necessary git repositories to demonstrate the problem.