In fact is it possible? Nothing changed as far as git is concerned.

Good catch. It used to be necessary before there was a git-annex branch, but not now.

After doing the above with two required copy per file, git annex fsck complained that I had only one copy per file even though I had created my clone, already. Once I git pulled from the second repo, not getting any changes for obvious reasons, git annex fsck was happy. So I am not sure how my addition was incorrect. -- RichiH

• why the git remote add laptop ~/annex ? this remote already exists under the name origin.
• doesn't the last command need to be git remote add usbdrive /media/usb/annex? because the actual repo would be in /media/usb/annex, not /media/usb?

I may be missing something obvious, but when I copy to a remote repository, the object files are created, but no softlinks are created. When I pull everything from the remote, it pulls only files the local repo knows about already.

    A
   / \
  B   C

Moving from B to A creates no symlinks in A but the object files are moved to A. Copying back from A to B restores the object files in B and keeps them in A.

Copying from A to an empty C does not create any object files nor symlinks. Copying from C to A creates no symlinks in A but the object files are copied to A.

-- RichiH

Good spotting on the last line, fixed.

The laptop remote is indeed redundant, but it leads to clearer views of what is going on later in the walkthrough ("git pull laptop master", "(copying from laptop...)"). And if the original clone is made from a central bare repo, this reinforces that you'll want to set up remotes for other repos on the computer.

Yes, you have to pull down location tracking information in order for fsck to be satisfied in that situation. But since this is a walkthrough, and neither fsck or numcopies settings are mentioned until later, it's ok for this pull to be described a few steps along in getting file content.

git annex move only moves content. All symlink management is handled by git, so you have to keep repositories in sync using git as you would any other repo. When you git pull B in A, it will get whatever symlinks were added to B.

(It can be useful to use a central bare repo and avoid needing to git pull from one repo to another, then you can just always push commits to the central repo, and pull down all changes from other repos.)

I would not mind if the walkthrough documented the central git repo case. But I don't want to complicate it unduely (it's long enough), and it's important that the fully distributed case be shown to work, and I assume that people already have basic git knowledge, so documenting the details of set up of a bare git repo is sorta out of scope. (There are also a lot of way to do it, using github, or gitosis, or raw git, etc.)

Ah yes, I feel kinda stupid in hindsight.

As the central server is most likely a common use case, would you object if I added that to the walkthrough? If you have any best practices on how to automate a push with every copy to a bare remote? AFAIK, git does not store information about bare/non-bare remotes, but this could easily be put into .git/config by git annex.

-- RichiH