New annex.supportunlocked config

Can beet to false to avoid some expensive things needed to support unlocked
files.

See my comment for why this only controls what init sets up, and not other
behavior.

I didn't bother with making the v5 upgrade code path look at this, though
it easily could, because the docs say to run git-annex init after setting
it to make it take effect.

Annex/Init.hs

@@ -128,10 +128,14 @@ initialize' mversion = checkInitializeAllowed $ do
 	setDifferences
 	unlessM (isJust <$> getVersion) $
 		setVersion (fromMaybe defaultVersion mversion)
-	configureSmudgeFilter
+	supportunlocked <- annexSupportUnlocked <$> Annex.getGitConfig
+	if supportunlocked
+		then configureSmudgeFilter
+		else deconfigureSmudgeFilter
 	unlessM isBareRepo $ do
-		showSideAction "scanning for unlocked files"
+		when supportunlocked $ do
-		scanUnlockedFiles
+			showSideAction "scanning for unlocked files"
+			scanUnlockedFiles
 		hookWrite postCheckoutHook
 		hookWrite postMergeHook
 	AdjustedBranch.checkAdjustedClone >>= \case

CHANGELOG

@@ -21,6 +21,8 @@ git-annex (8.20210311) UNRELEASED; urgency=medium
   * fsck: When --from is used in combination with --all or similar options,
     do not verify required content, which can't be checked properly when
     operating on keys.
+  * New annex.supportunlocked config that can be set to false to avoid
+    some expensive things needed to support unlocked files.
 
  -- Joey Hess <id@joeyh.name>  Fri, 12 Mar 2021 12:06:37 -0400
 

Types/GitConfig.hs

@@ -128,6 +128,7 @@ data GitConfig = GitConfig
 	, annexCommitMode :: CommitMode
 	, annexSkipUnknown :: Bool
 	, annexAdjustedBranchRefresh :: Integer
+	, annexSupportUnlocked :: Bool
 	, coreSymlinks :: Bool
 	, coreSharedRepository :: SharedRepository
 	, receiveDenyCurrentBranch :: DenyCurrentBranch
@@ -229,6 +230,7 @@ extractGitConfig configsource r = GitConfig
 		-- parse as bool if it's not a number
 		(if getbool "adjustedbranchrefresh" False then 1 else 0)
 		(getmayberead (annexConfig "adjustedbranchrefresh"))
+	, annexSupportUnlocked = getbool (annexConfig "supportunlocked") True
 	, coreSymlinks = getbool "core.symlinks" True
 	, coreSharedRepository = getSharedRepository r
 	, receiveDenyCurrentBranch = getDenyCurrentBranch r

doc/git-annex.mdwn

@@ -1171,6 +1171,20 @@ repository, using [[git-annex-config]]. See its man page for a list.)
   And when multiple files in the work tree have the same content, only
   one of them gets hard linked to the annex.
 
+* `annex.supportunlocked'
+
+  By default git-annex supports unlocked files as well as locked files,
+  so this defaults to true. If set to false, git-annex will only support
+  locked files. That will avoid doing the work needed to support unlocked
+  files.
+
+  Note that setting this to false does not prevent a repository from
+  having unlocked files added to it, and in that case the content of the
+  files will not be accessible until they are locked.
+
+  After changing this config, you need to re-run `git-annex init` for it
+  to take effect.
+
 * `annex.resolvemerge`
 
   Set to false to prevent merge conflicts in the checked out branch

doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_5_2aab5c685ad934486e60065b3c8da1bf._comment

@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-03-23T17:10:22Z"
+ content="""
+If we zoom out a bit, and also consider Ilya's desire to skip installing
+smudge/clean filters, maybe what you guys want is a way to tell git-annex
+that a particular repo does not use unlocked files, so git-annex can
+avoid expensive stuff needed to support them.
+
+So, I've added an `annex.supportunlocked` config that can be set to false
+before running `git-annex init`, and it will disable the smudge filters
+and skip this expensive scan.
+
+(The config will also let you measure the actual time this scan takes,
+which I'm still curious about, because I've not seen it being a majority of
+the init time, even in a large repository. Seems likely to me that init is
+doing other expensive things right after this scan, in particular setting
+up the git-annex branch, and that it may be those are what was really
+seeming slow to you.)
+
+The config as implemented does not prevent later adding unlocked files, and
+if you do that, git-annex will get confused and not make the content
+accessible until you change the config back and re-run git-annex init, or
+you lock the file.
+
+While the config could grow in scope to preventing adding
+unlocked files, it seems like probably a bad idea (and a whole lot of work).
+For one thing `git add` with a largefiles configuration would then
+need to prevent adding the file unlocked.. but it can't add it locked, and
+the smudge filter can't prevent git from adding the file -- so it would
+need to ignore the largefiles configuration and add the file to git. Which
+could be pretty suprising.
+
+And really there's no way for git-annex to enforce that a repo doesn't
+contain unlocked files. Even if this became a repo-global config (probably
+not a good idea), someone could merge new unlocked files from a repo that
+does, using just git. Or add them using an old version of git-annex. (Or
+just convert symlinks to unlocked files manually, it's not hard..) If
+setting this config, you're telling git-annex you don't expect there to be
+any unlocked file, and are ok with some minor breakage if there are some.
+
+Combining the config with `git-annex adjust --lock` would somewhat
+avoid such problems, although it's still possible to add files
+unlocked when in such a branch.
+"""]]