Remove temporary code added in 6.20160619 to prime the mergedrefs log.

Repositories that are upgraded from before that version to this
one will not break, but will just not see the benefit of the mergedrefs log
speeding things up, until one new ref gets merged in.

1 files changed, 20 insertions, 0 deletions

diff --git a/doc/bugs/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_1_8b60c52d8fe41718377d6d15a25cae97._comment b/doc/bugs/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_1_8b60c52d8fe41718377d6d15a25cae97._comment
new file mode 100644
index 000000000..efef1a0e3
--- /dev/null
+++ b/doc/bugs/impossible_to_perform___34__read-only__34___git_annex_info_without_write_permissions/comment_1_8b60c52d8fe41718377d6d15a25cae97._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-02-22T16:17:35Z"
+ content="""
+The mergedrefs directory is used while building the commit to merge
+git-annex branches. So even if it was written someplace else, that commit
+would fail.
+
+I think this may be happening even when there are no
+git-annex refs to merge in, due to the transition code
+in Annex.Branch.updateTo that temporarily calls addMergedRefs
+in the "null tomerge" case. That was added in 2016, and is flagged as able
+to be safely removed. I've removed it.
+
+However, when there actually is a git-annex branch to merge, if a
+hypothetical readonly mode avoided doing so, it would necessarily see a
+different state of the git-annex branch than would be seen in non-readonly
+mode. That behavior difference could be fairly confusing potentially..
+"""]]