I am not sure this is the case, but from first-hand experience, it sure looks like you can't turn on v7 (or really v6, actually) on a single git worktree. For example, if I have my pictures repository on curie and turn on v7, angela will also need to run git annex upgrade on their worktree otherwise git-annex (e.g. 6.20180913-1~bpo9+1 on Debian stretch) will be really confused:

anarcat@angela:calendes$ less calendrier/calendes.pdf
anarcat@angela:calendes$ git annex get calendrier/calendes.pdf
anarcat@angela:calendes$ git annex whereis calendrier/calendes.pdf
anarcat@angela:calendes$ # OMG WHERE ARE MY FILES! /me flails wildly


It seems to me there should be a warning in the upgrades page about this. I would have done so myself, but I'm not sure (like in my last bug report) if I am doing things right.

In this case, this repository was already present (v5, indirect mode) on both machines. I upgraded (using git annex upgrade) the repository on curie (7.20181121 Debian buster) which went well.

(Then I messed around with that thumb drive, which led to ?v7 fails to fetch files on FAT filesystem, but probably unrelated here.)

Then i powered on my laptop (angela) and saw the above. I would have expected it to either upgrade automatically or warn me about the repository inconsistency. Of failing that, the upgrades page should at least warn us this is a "system-wide" (how do we call that?) change...

The workaround is to run git annex upgrade on that other repo, of course, but if the source repo was also upgraded, it might be difficult to sync files, as you will see that warning:

$ git annex get
get calendrier/calendes.pdf (from sneakernet...) 
Repository version 7 is not supported. Upgrade git-annex.

Considering there's no backport of 7.x in Debian stretch, it makes the upgrade path rather delicate... Is there a way to "downgrade" that sneakernet repo? :) (Thankfully, the main server still runs v5 so the files are still accessible from stretch....) -- anarcat

Updated the upgrades page, done.