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

@@ -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 <id@joeyh.name>  Mon, 11 Nov 2024 12:26:00 -0400
 

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) 
-		(oldvs, vs) <- splitAt (num - 1) . filter (sameparentbranch v)
+			. filter (sameparentbranch v)
+			. filter (/= v)
 			<$> recentViews
-		mapM_ removeView oldvs
+		let removeview = mapM_ removeView (v : oldvs)
-		case vs of
+		ok <- case vs of
-			(oldv:_) -> next $ do
+			(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 

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..
+"""]]