analysis and followup

This commit is contained in:
Joey Hess 2023-04-20 14:11:04 -04:00
parent 2de88e299f
commit 2752360708
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 72 additions and 0 deletions

View file

@ -0,0 +1,31 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2023-04-20T17:51:01Z"
content="""
Notice that your script is doing something a bit unusual. You check out a
branch, add the submodule in that branch, and then check out the original
branch, which is before the submodule was added.
So, git needs to delete the submodule. Deleting the submodule is
mentioned in [[submodules]] as a particular case where git-annex's hack to
support submodules does not work very well.
If that's all this bug is about, its description is over-broad.
It doesn't seem to prevent using submodules with git-annex in situations
where you are not deleting a submodule, but are updating submodules
Yes, `git checkout main --recurse-submodules` will fail in those
situations, but the workaround in [this comment](https://git-annex.branchable.com/submodules/#comment-0d7c31e3f08e803bf9b13ab0568fedcc)
of using `git checkout main && git submodule update` will work.
And yes, I've verified that does still work, with git 2.40.0.
I modified the test case to add the submodule before checking out
the branch, then add `sub_file2.txt`, and commit that to the branch.
At that point, `git checkout main && git submodule update` worked fine.
So, nothing changed in git, and git-annex's approach for submodules does
broadly work, except git has issues deleting submodules that have a .git
directory in them. The solution is to `rm -rf` the submodule after
running `git checkout`.
"""]]

View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2023-04-20T18:04:56Z"
content="""
I don't think it's possible to improve git-annex's behavior here much.
git-annex could avoid converting .git file to a directory, but then the
git-annex symlinks would point to the wrong place. It could, when in a
submodule, make the git-annex symlinks point up to ../.git/modules/sub/,
but then the links would not work when the submodule was cloned by itself,
or when the submodule was located at a different directory level.
The only other thing git-annex can do is avoid using symlinks at all,
eg adjusted unlocked branches. I don't think it's a good trafeoff to do
that. On the one hand, there is this minor issue with submodule deletion,
and the need to avoid using `--recurse-submodules` and instead do `git
submodule update`. On the other hand, unlocked annexed files use 2x
as much disk space.
"""]]

View file

@ -0,0 +1,21 @@
[[!comment format=mdwn
username="joey"
subject="""comment 5"""
date="2023-04-20T16:45:38Z"
content="""
The above issue is being discussed at
[[bugs/Git_checkout_fails_using_--recurse-submodules]].
DavidD's comment #2 is misleading, `git submodule update` does work fine when
you've checkout out a branch and want to update an existing submodule.
When `git submodule update` does not work 100% is the case where you checked out
a branch, added a submodule in that branch, and then checked out another
branch that does not contain the submodule. What happens then is:
warning: unable to rmdir 'sub': Directory not empty
And the solution is to `rm -rf sub` manually. This is essentially the same
problem discussed above on this page where it talks about deleting a whole
submodule.
"""]]