When a local clone was at v7 and gets upgraded to v8 by a command run in
a repo that has it as a remote, this is displayed:

"fatal: ../path/to/clone is outside repository"

This happens because git ls-files is run to list the files of the clone.
But, it has some strange behavior when relative paths are used. Result is
it always fails. 

This also causes the keys database of the clone to not get
repopulated after being deleted for the upgrade. 
That's not a fatal problem because git-annex is always prepared for the
keys database being out of date, but it could result in considerably more
work being done later.

Also, the associated files does not get repopulated when it fails like
that. That could cause worse problems. I have not tried to see what happens
when the repo that fails to be upgraded has unlocked files.

I also found some v1 upgrade code that does the same thing, and presumably
also has the problem, although there are probably no v1 repos left. 
This seems like it could be a larger problem that only upgrades, but
luckily upgrades seem like the only time that git-annex, running in one
repo, needs to do anything involving listing the files in the working tree
of a remote.

Hmm, Upgrade.V5 also has a LsFiles.stagedDetails
that looks like it would have then problem. That would affect upgrading
from a V5 direct mode repo to V6.

--[[Joey]

> Fixed all such upgrade bugs by changing how local remotes are upgraded,
> running git-annex upgrade inside the remote.
> 
> Also, guarded all git ls-files calls with a check that it's not being
> run on a local remote, just in case there are other such bugs.
> 
> [[done]] --[[Joey]]