init: fix data loss bug
Fix bug that lost modifications to unlocked files when init is re-ran in an already initialized repo. In retrospect needing scanUnlockedFiles False in the direct mode upgrade path was a good hint that it was unsafe when used with True. However, this bug did not affect upgrade from v5. In such an upgrade, an unlocked file that is modified is left as-is. The only place scanUnlockedFiles True did overwrite modified unlocked files is during an git-annex init of a repo that was already initialized by git-annex. (I also tried a scenario where the repo had not been initialized by git-annex yet, but was cloned from a v7 repo with an unlocked file, and the pointer file replaced with some other content, and the data loss did not occur in that situation.) Since the fixed scanUnlockedFiles avoids overwriting non-pointer files, it should be safe to run in any situation, so there's no need any longer for the parameter.
This commit is contained in:
parent
3cb2427dbc
commit
e2d4c133f5
4 changed files with 23 additions and 20 deletions
|
@ -42,13 +42,10 @@ upgrade automatic = flip catchNonAsync (const $ return False) $ do
|
|||
( do
|
||||
checkGitVersionForDirectUpgrade
|
||||
convertDirect
|
||||
-- Worktree files are already populated, so don't
|
||||
-- have this try to populate them again.
|
||||
scanUnlockedFiles False
|
||||
, do
|
||||
checkGitVersionForIndirectUpgrade
|
||||
scanUnlockedFiles True
|
||||
)
|
||||
scanUnlockedFiles
|
||||
configureSmudgeFilter
|
||||
-- Inode sentinal file was only used in direct mode and when
|
||||
-- locking down files as they were added. In v6, it's used more
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue