fixed
This commit is contained in:
parent
7a8393ce7d
commit
9f6609d2b1
3 changed files with 47 additions and 0 deletions
|
@ -90,3 +90,4 @@ I didn't check `move` command but if it does support similar `--from --to` and h
|
|||
[[!tag projects/dandi]]
|
||||
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
|
@ -0,0 +1,27 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2023-11-17T20:33:01Z"
|
||||
content="""
|
||||
That bug I fixed would also explain the behavior that you saw if the
|
||||
content *was* present locally, and the location log *was* out of date about
|
||||
that.
|
||||
|
||||
In that situation, git-annex sees that the object file is present, and so
|
||||
treats the content as present, despite the location log not knowing it's
|
||||
present. Which triggers the situation of the bug I fixed, causing it to
|
||||
skip copying the file.
|
||||
|
||||
Also, there's a pretty easy way to get into this situation. When the file
|
||||
is not present, run `git-annex --from --to`. Then interrupt it after it's
|
||||
downloaded the file --from but before it's finished sending it --to.
|
||||
This results in the file being present locally, but only transiently so it
|
||||
didn't update the location log.
|
||||
|
||||
So my guess is you interrupted a copy like that (or it failed incomplete
|
||||
for whatever reason).
|
||||
|
||||
Now that I've fixed that bug, the behavior in that situation is that it
|
||||
does copy the file to the remote. And then it drops the local copy since
|
||||
the location log doesn't contain it. So it resumes correctly now.
|
||||
"""]]
|
|
@ -0,0 +1,19 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 4"""
|
||||
date="2023-11-17T20:42:24Z"
|
||||
content="""
|
||||
So that leaves only the question of what it should do when
|
||||
content is present locally but not on the --from remote.
|
||||
|
||||
Another reason for the current behavior is to be symmetric with `git-annex
|
||||
move --from foo --to bar`. It would be surprising, I think, if that
|
||||
populated bar with files that are not present in foo, but are in the local
|
||||
repository!
|
||||
|
||||
So I'm inclined to not change the documented behavior. If you want to
|
||||
populate a remote with files that are either in the local repo or in a
|
||||
--from remote, you can just run `git-annex copy` twice after all.
|
||||
|
||||
(Or there could be a new option like `git-annex copy --to bar --from foo --or-from-here`)
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue