From 0802fdbb6aa04865a677e5c9eedc158c66619f5f Mon Sep 17 00:00:00 2001 From: lealanko Date: Mon, 7 Sep 2015 12:33:02 +0000 Subject: [PATCH] --- ..._no_longer_set_on_init_of_shared_repo.mdwn | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 doc/bugs/annex.hardlink_no_longer_set_on_init_of_shared_repo.mdwn diff --git a/doc/bugs/annex.hardlink_no_longer_set_on_init_of_shared_repo.mdwn b/doc/bugs/annex.hardlink_no_longer_set_on_init_of_shared_repo.mdwn new file mode 100644 index 0000000000..23d9c95f26 --- /dev/null +++ b/doc/bugs/annex.hardlink_no_longer_set_on_init_of_shared_repo.mdwn @@ -0,0 +1,24 @@ +### 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!