complication
This commit is contained in:
parent
ce1c47b658
commit
3fba7910d2
1 changed files with 24 additions and 0 deletions
|
@ -0,0 +1,24 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 5"""
|
||||
date="2025-07-11T18:38:59Z"
|
||||
content="""
|
||||
When a secondary worktree is used on a filesystem not supporting symlinks,
|
||||
it would be possible for `git-annex move` to move an object from another
|
||||
repository. And store it to the wrong location, under
|
||||
`.git/worktrees/foo/annex/objects/`. The object would still be accessible,
|
||||
and a later `git-annex copy --to remote`, if run in the same worktree,
|
||||
would be able to send the object on to a remote.
|
||||
|
||||
But if this bug gets fixed, then the misplaced object file will be left,
|
||||
and won't be used any longer. Which could appear to the user as data loss
|
||||
in some situations. Eg, the copy to the remote would fail. (There might be
|
||||
situations where the populated worktree file would be used as a copy of the
|
||||
object, but that assumes the worktree file is still populated.)
|
||||
|
||||
Also, `git-annex drop` would not delete such misplaced object files, so the
|
||||
user would be left with bloated repository.
|
||||
|
||||
So, `git-annex fsck` will need to be made to search out such misplaced
|
||||
object files and move them to the correct objects directory.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue