### Please describe the problem.

In an earlier git-annex version (5.20141125, at least on debian), `git clone --shared` followed by `git annex init` used to set annex.hardlink to true and mark the repository as untrusted. It no longer does that.

### What steps will reproduce the problem?

(Assuming "foo" is a pre-existing repo with an annex)

    git clone --shared foo foo.shared
    cd foo.shared
    git annex init
    git config annex.hardlink

### What version of git-annex are you using? On what operating system?

5.20150824, Debian Jessie. Tried both the debian unstable package and direct cabal build.

### Please provide any additional information below.

I haven't really debugged this, but it seems that `git annex init` nowadays does some syncing (i.e. commits, i.e. objects) that it didn't used to. The hard link check tests that the current repository has alternates, but doesn't have local objects. It might be that the newly created local objects prevent the hard link check from passing. Perhaps the hard link test should only check the presence of alternates?

### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)

Sure, it's a great tool!

> Seems that bit rotted at some point. I've fixed it, and put in a test
> case. [[done]] --[[Joey]]