mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

reproed

Browse source
This commit is contained in:
Joey Hess 2025-07-11 12:16:25 -04:00
parent 072f2606a1
commit 93eb7864c8
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 28 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

28
doc/bugs/Missing_file_content_in_secondary_worktree___40__win__41__/comment_1_a431120abf810e41b03a071eb748ea8b._comment Normal file
View file

@ -0,0 +1,28 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2025-07-11T16:05:53Z"
content="""
I reproduced the same behavior on linux, when using a FAT filesystem.
So, this has something to do with automatic entry of an unlocked adjusted
branch on a crippled filesystem.
Interestingly, doing the same on ext4, and manually using `git-annex
unlock` on the file and committing before checking out the worktree does
not replicate the problem. The unlocked file is automatically populated on
worktree checkout there. And manual `git-annex adjust --unlock` before
worktree creation also doesn't have the problem, even though the worktree
does end up in an adjusted unlocked branch.
(The output of `git-annex get` is also weird. I think what's happening is
that, since the unlocked file is not populated, it is enumerated as a file
that `get` can operate on. But then when it runs, since there is no other
location, it displays that message. The command does not have anything to
handle this unusual case of the file being a pointer file but its content
being present in the repisitory. And, usually there is no way that can
happen, eg even writing a pointer file manually followed by `git add` of it
populates it. So I think this unusual behavior of `git-annex get` doesn't
need to change, once this bug is fixed it should not be possible to see
that behavior.)
"""]]