Remove fixup code for bad bare repositories created by versions 5.20131118 through 5.20131127. That fixup code would accidentially fire when --git-dir was incorrectly pointed at the working tree of a git-annex repository, resulting in data loss. Closes: #768093

Annex/Init.hs

@@ -107,9 +107,7 @@ uninitialize = do
  - Checks repository version and handles upgrades too.
  -}
 ensureInitialized :: Annex ()
-ensureInitialized = do
-	getVersion >>= maybe needsinit checkUpgrade
-	fixBadBare
+ensureInitialized = getVersion >>= maybe needsinit checkUpgrade
   where
 	needsinit = ifM Annex.Branch.hasSibling
 			( initialize Nothing
@@ -194,60 +192,6 @@ enableDirectMode = unlessM isDirect $ do
 		maybe noop (`toDirect` f) =<< isAnnexLink f
 	void $ liftIO clean
 
-{- Work around for git-annex version 5.20131118 - 5.20131127, which
- - had a bug that unset core.bare when initializing a bare repository.
- - 
- - This resulted in objects sent to the repository being stored in 
- - repo/.git/annex/objects, so move them to repo/annex/objects.
- -
- - This check slows down every git-annex run somewhat (by one file stat),
- - so should be removed after a suitable period of time has passed.
- - Since the bare repository may be on an offline USB drive, best to
- - keep it for a while. However, git-annex was only buggy for a few
- - weeks, so not too long.
- -}
-fixBadBare :: Annex ()
-fixBadBare = whenM checkBadBare $ do
-	ks <- getKeysPresent InAnnex
-	liftIO $ debugM "Init" $ unwords
-		[ "Detected bad bare repository with"
-		, show (length ks)
-		, "objects; fixing"
-		]
-	g <- Annex.gitRepo
-	gc <- Annex.getGitConfig
-	d <- Git.repoPath <$> Annex.gitRepo
-	void $ liftIO $ boolSystem "git"
-		[ Param $ "--git-dir=" ++ d
-		, Param "config"
-		, Param Git.Config.coreBare
-		, Param $ Git.Config.boolConfig True
-		]
-	g' <- liftIO $ Git.Construct.fromPath d
-	s' <- liftIO $ Annex.new $ g' { Git.location = Git.Local { Git.gitdir = d, Git.worktree = Nothing } }
-	Annex.changeState $ \s -> s
-		{ Annex.repo = Annex.repo s'
-		, Annex.gitconfig = Annex.gitconfig s'
-		}
-	forM_ ks $ \k -> do
-		oldloc <- liftIO $ gitAnnexLocation k g gc
-		thawContentDir oldloc
-		moveAnnex k oldloc
-		logStatus k InfoPresent
-	let dotgit = d </> ".git"
-	liftIO $ removeDirectoryRecursive dotgit
-		`catchIO` const (renameDirectory dotgit (d </> "removeme"))
-
-{- A repostory with the problem won't know it's a bare repository, but will
- - have no pre-commit hook (which is not set up in a bare repository),
- - and will not have a HEAD file in its .git directory. -}
-checkBadBare :: Annex Bool
-checkBadBare = allM (not <$>)
-	[isBare, hasPreCommitHook, hasDotGitHEAD]
-  where
-	hasPreCommitHook = inRepo $ doesFileExist . hookFile preCommitHook
-	hasDotGitHEAD = inRepo $ \r -> doesFileExist $ Git.localGitDir r </> "HEAD"
-
 checkSharedClone :: Annex ()
 checkSharedClone = whenM (inRepo Git.Objects.isSharedClone) $ do
 	showSideAction "Repository was cloned with --shared; setting annex.hardlink=true and making repository untrusted."

debian/changelog

@@ -1,5 +1,10 @@
 git-annex (5.20141025) UNRELEASED; urgency=medium
 
+  * Remove fixup code for bad bare repositories created by
+    versions 5.20131118 through 5.20131127. That fixup code would
+    accidentially fire when --git-dir was incorrectly
+    pointed at the working tree of a git-annex repository,
+    resulting in data loss. Closes: #768093
   * Windows: Fix crash when user.name is not set in git config.
 
  -- Joey Hess <joeyh@debian.org>  Fri, 31 Oct 2014 16:13:43 -0400

doc/bugs/misuse_of_--git-dir_might_destroy_a_git_repository_completely.mdwn

@@ -30,3 +30,5 @@ I am running Debian sid.
 
 # End of transcript or log.
 """]]
+
+> [[fixed|done]] --[[Joey]]

doc/bugs/misuse_of_--git-dir_might_destroy_a_git_repository_completely/comment_1_5c0bdeb0e1fc6b2d524e5c33ff80ce8a._comment

@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""yikes!"""
+ date="2014-11-04T21:47:07Z"
+ content="""
+I'm very sorry you encountered this bug. I'd like to do anything
+possible to recover your repository. While investigating it, it looks
+like, when the repository is not a fresh and empty repo, it doesn't
+actually get completely nuked. Instead, the contents of the .git directory,
+including annexed objects, is left in "removeme". It should be possible to
+mostly recover from that. I can try to walk you through it if necessary.
+
+I know exactly what the cause of this bug is. It's a workaround for a bug
+in some by now quite old versions of git-annex (from last year). That old bug
+caused a .git/.git directory to be created, and so this workaround looks
+for $GIT_DIR/.git and does what turn out to be horrible things in this
+case.
+
+So, I have immediately removed that old workaround, so noone else will
+encounter this.
+"""]]