git-remote-annex: Fix cloning from a special remote on a crippled filesystem

Not initializing and so deleting the bundles only causes a little more work
on the first git fetch.
This commit is contained in:
Joey Hess 2024-11-19 12:43:51 -04:00
parent 1ff54a3b44
commit df29f29e0d
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 28 additions and 2 deletions

View file

@ -15,6 +15,8 @@ git-annex (10.20241032) UNRELEASED; urgency=medium
unversioned S3 bucket that is large enough to need pagination.
* S3: Use significantly less memory when importing from a
versioned S3 bucket.
* git-remote-annex: Fix cloning from a special remote on a crippled
filesystem.
-- Joey Hess <id@joeyh.name> Mon, 11 Nov 2024 12:26:00 -0400

View file

@ -1129,7 +1129,7 @@ specialRemoteFromUrl sab a = withTmpDir "journal" $ \tmpdir -> do
-- If the git-annex branch did not exist when this command started,
-- it was created empty by this command, and this command has avoided
-- making any other commits to it, writing any temporary annex branch
-- changes to thre alternateJournal, which can now be discarded.
-- changes to the alternateJournal, which can now be discarded.
--
-- If nothing else has written to the branch while this command was running,
-- the branch will be deleted. That allows for the git-annex branch that is
@ -1152,6 +1152,11 @@ specialRemoteFromUrl sab a = withTmpDir "journal" $ \tmpdir -> do
-- does not contain any hooks. Since initialization installs
-- hooks, have to work around that by not initializing, and
-- delete the git bundle objects.
--
-- Similarly, when on a crippled filesystem, doing initialization would
-- involve checking out an adjusted branch. But git clone wants to do its
-- own checkout. So no initialization is done then, and the git bundle
-- objects are deleted.
cleanupInitialization :: StartAnnexBranch -> FilePath -> Annex ()
cleanupInitialization sab alternatejournaldir = void $ tryNonAsync $ do
liftIO $ mapM_ removeFile =<< dirContents alternatejournaldir
@ -1173,7 +1178,7 @@ cleanupInitialization sab alternatejournaldir = void $ tryNonAsync $ do
Nothing -> return ()
Just _ -> void $ tryNonAsync $
inRepo $ Git.Branch.delete Annex.Branch.fullname
ifM (Annex.Branch.hasSibling <&&> nonbuggygitversion)
ifM (Annex.Branch.hasSibling <&&> nonbuggygitversion <&&> notcrippledfilesystem)
( do
autoInitialize' (pure True) startupAnnex remoteList
differences <- allDifferences <$> recordedDifferences
@ -1190,6 +1195,8 @@ cleanupInitialization sab alternatejournaldir = void $ tryNonAsync $ do
_ -> noop
void $ liftIO $ tryIO $ removeDirectory (decodeBS annexobjectdir)
notcrippledfilesystem = not <$> probeCrippledFileSystem
nonbuggygitversion = liftIO $
flip notElem buggygitversions <$> Git.Version.installed
buggygitversions = map Git.Version.normalize

View file

@ -0,0 +1,17 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2024-11-19T16:18:31Z"
content="""
This is a new test.
Looks like it's found a legitimate bug in git-remote-annex. When the
filesystem is crippled, the git-annex init checks out an adjusted branch,
which here happens in the middle of git's own checkout and so legitimately
confuses git.
I can reproduce this on a FAT filesystem, cloning from eg a directory
special remote. Fixed this.
(The OSX failure is something else.)
"""]]