From 798f6850777f405ccd6cd83d5398e7b39812c2c3 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 23 Mar 2021 14:04:34 -0400 Subject: [PATCH] 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 | 10 ++-- CHANGELOG | 2 + Types/GitConfig.hs | 2 + doc/git-annex.mdwn | 14 ++++++ ..._2aab5c685ad934486e60065b3c8da1bf._comment | 46 +++++++++++++++++++ 5 files changed, 71 insertions(+), 3 deletions(-) create mode 100644 doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_5_2aab5c685ad934486e60065b3c8da1bf._comment diff --git a/Annex/Init.hs b/Annex/Init.hs index 331c82a9d2..cea69f8237 100644 --- a/Annex/Init.hs +++ b/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" - scanUnlockedFiles + when supportunlocked $ do + showSideAction "scanning for unlocked files" + scanUnlockedFiles hookWrite postCheckoutHook hookWrite postMergeHook AdjustedBranch.checkAdjustedClone >>= \case diff --git a/CHANGELOG b/CHANGELOG index fad4a75942..e3bf6cf0c0 100644 --- a/CHANGELOG +++ b/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 Fri, 12 Mar 2021 12:06:37 -0400 diff --git a/Types/GitConfig.hs b/Types/GitConfig.hs index 6a9e572c88..aa5e6c65b5 100644 --- a/Types/GitConfig.hs +++ b/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 diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn index aca92e37b4..be9fd7e257 100644 --- a/doc/git-annex.mdwn +++ b/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 diff --git a/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_5_2aab5c685ad934486e60065b3c8da1bf._comment b/doc/todo/Avoid_lengthy___34__Scanning_for_unlocked_files_...__34__/comment_5_2aab5c685ad934486e60065b3c8da1bf._comment new file mode 100644 index 0000000000..3cf9b89631 --- /dev/null +++ b/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. +"""]]