From 447e6adabd0627d6b970d3859fa192b5ea64f8ee Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 11 Nov 2024 14:15:51 -0400 Subject: [PATCH] vpop: Only update state after successful checkout If checkout fails for some reason, they're still in a view, and should be able to vpop again. --- CHANGELOG | 1 + Command/VPop.hs | 19 +++++++++---- ..._7b29f41866000bbdcd1e90b3a3105716._comment | 28 +++++++++++++++++++ 3 files changed, 42 insertions(+), 6 deletions(-) create mode 100644 doc/forum/Stuck_in_git_annex_view__58___file_name_too_long/comment_2_7b29f41866000bbdcd1e90b3a3105716._comment diff --git a/CHANGELOG b/CHANGELOG index b025184df3..1fda614aa9 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -2,6 +2,7 @@ git-annex (10.20241032) UNRELEASED; urgency=medium * git-remote-annex: Fix a reversion introduced in version 10.20241031 that broke cloning from a special remote. + * vpop: Only update state after successful checkout. -- Joey Hess Mon, 11 Nov 2024 12:26:00 -0400 diff --git a/Command/VPop.hs b/Command/VPop.hs index a5fac3ac37..80912b4486 100644 --- a/Command/VPop.hs +++ b/Command/VPop.hs @@ -28,22 +28,29 @@ start ps = go =<< currentView where go Nothing = giveup "Not in a view." go (Just (v, madj)) = starting "vpop" ai si $ do - removeView v - (oldvs, vs) <- splitAt (num - 1) . filter (sameparentbranch v) + (oldvs, vs) <- splitAt (num - 1) + . filter (sameparentbranch v) + . filter (/= v) <$> recentViews - mapM_ removeView oldvs - case vs of - (oldv:_) -> next $ do + let removeview = mapM_ removeView (v : oldvs) + ok <- case vs of + (oldv:_) -> do showOutput checkoutViewBranch oldv madj (\v' madj' -> return (branchView v' madj')) - _ -> next $ do + _ -> do showOutput inRepo $ Git.Command.runBool [ Param "checkout" , Param $ Git.fromRef $ Git.Ref.base $ viewParentBranch v ] + if ok + then + next $ do + removeview + return True + else next $ return False sameparentbranch a b = viewParentBranch a == viewParentBranch b num = fromMaybe 1 $ readish =<< headMaybe ps diff --git a/doc/forum/Stuck_in_git_annex_view__58___file_name_too_long/comment_2_7b29f41866000bbdcd1e90b3a3105716._comment b/doc/forum/Stuck_in_git_annex_view__58___file_name_too_long/comment_2_7b29f41866000bbdcd1e90b3a3105716._comment new file mode 100644 index 0000000000..9fdaa9546b --- /dev/null +++ b/doc/forum/Stuck_in_git_annex_view__58___file_name_too_long/comment_2_7b29f41866000bbdcd1e90b3a3105716._comment @@ -0,0 +1,28 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2024-11-11T17:56:35Z" + content=""" +This can certainly happen if files in the repository are in a directory +path that, when converted to a filename, is too long. + +I tried reproducing it, and was basically able to get into the same state +as you. The reason both "git-annex vpop" and "git checkout master" fail +is that since the long files were staged in git, but unable to be written, +git considers them to be deleted. And so it refuses to do a checkout, +with "Your local changes to the following files would +be overwritten by checkout" + +I was able to resolve it by deleting the directory that contained those +too long files. Which was empty anyway. That made git treat those files +as deleted, and allowed "git checkout master" to work, as well as +"git-annex vpop". + +The reason "git-annex vpop" failed for you with "Not in a view" is that was +actually the second time you ran it, and the first time, despite the git +checkout failing, it had proceeded to update git-annex's state to say it had +popped out of the view. I've fixed that bug. + +As to whether git-annex should try to detect this and avoid entering such a +view, I dunno.. +"""]]