fix a bug that prevented git-annex init from working in a submodule
authorJoey Hess <joeyh@joeyh.name>
Thu, 21 Jan 2021 19:33:15 +0000 (15:33 -0400)
committerJoey Hess <joeyh@joeyh.name>
Thu, 21 Jan 2021 19:33:15 +0000 (15:33 -0400)
This is probably a reversion, but not sure what caused it. By the time
Annex.Init runs fixupUnusualReposAfterInit, another git-annex process has
at least sometimes already done the necessary fixups. (Eg, one run
indirectly by a git command.) But since the Repo is cached, it doesn't
realize and does them again. So, avoid crashing when git config --unset
fails.

This commit was sponsored by Jack Hill on Patreon.

Annex/Fixup.hs
CHANGELOG
doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_.mdwn
doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_5_06d31ed5a8c187cec7bc90339550b5e8._comment [new file with mode: 0644]

index 8730b83230930f67d6dda7283bda157dd695c37d..a60e4baa0b024fac473da2e64c49df868a4de2fc 100644 (file)
@@ -115,9 +115,8 @@ fixupUnusualRepos r@(Repo { location = l@(Local { worktree = Just w, gitdir = d
                removeWhenExistsWith R.removeLink dotgit
                R.createSymbolicLink linktarget dotgit
        
-       unsetcoreworktree =
-               maybe (giveup "unset core.worktree failed") (\_ -> return ())
-                       =<< Git.Config.unset "core.worktree" r
+       -- Unsetting a config fails if it's not set, so ignore failure.
+       unsetcoreworktree = void $ Git.Config.unset "core.worktree" r
        
        worktreefixup =
                -- git-worktree sets up a "commondir" file that contains
index fbb6904690592d663612912b9c82167606c39388..3b9bd58ef20983dbf17695fcbaf9002bbf21e299 100644 (file)
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -33,6 +33,7 @@ git-annex (8.20201130) UNRELEASED; urgency=medium
   * Directory special remotes with importtree=yes now avoid unncessary
     overhead when inodes of files have changed, as happens whenever a FAT
     filesystem gets remounted.
+  * Fix a bug that prevented git-annex init from working in a submodule.
 
  -- Joey Hess <id@joeyh.name>  Mon, 04 Jan 2021 12:52:41 -0400
 
index 25c5413369d0e367b839833d0bb60863df7cee23..ec55838884a064ef4b459084e677a681b69ab030 100644 (file)
@@ -36,3 +36,6 @@ Also the same on CentOS 7, I was just able to reproduce it on my F32 workstation
 
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 Besides this problem, I am super happy with git-annex and use it at work and at home daily :-)
+
+> [[fixed|done]] although w/o a way to reproduce it I can't be 100% sure
+> --[[Joey]]
diff --git a/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_5_06d31ed5a8c187cec7bc90339550b5e8._comment b/doc/bugs/warning__58___unable_to_convert_submodule_to_form_that_/comment_5_06d31ed5a8c187cec7bc90339550b5e8._comment
new file mode 100644 (file)
index 0000000..8655215
--- /dev/null
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2021-01-21T18:14:09Z"
+ content="""
+Thanks Mike, that confirms it's failing to unset the config that's not set.
+
+The .git symlink is what git-annex is supposed to set up, so it should not
+need to do anything else and the question is, why does it still think it 
+needs to change something?
+
+I was able to reproduce the warning, just run `git submodule add foo
+/path/to/annexrepo` and then in foo, `git-annex init` and then it
+happens part-way through. Due to two different git-annex processes both
+trying to do the same conversion, with the second one failing.
+I've fixed that. 
+
+My fix will also fix your problem. But, I don't actually
+understand how to reproduce your problem. I was only able to make it happen
+when running `git-annex init` (or letting it auto-init), 
+not running other git-annex commands in a repo it's already initialized.
+
+Maybe you have `GIT_DIR` set to "../../../.git/modules/..."?
+"""]]