comment
This commit is contained in:
parent
c2620ac4ca
commit
f2f6dbe46b
1 changed files with 57 additions and 0 deletions
|
@ -0,0 +1,57 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2023-11-17T19:58:39Z"
|
||||
content="""
|
||||
> -r--r--r-- 1 dandi dandi 3665589468 Mar 16 2023 sub-Fish41-GCaMP-vlgut-FBv-7dpf-RandomWave/sub-Fish41-GCaMP-vlgut-FBv-7dpf-RandomWave_ses-20210929T173736_behavior+ophys.nwb
|
||||
|
||||
This could be an unlocked file that has gotten modified but the staged
|
||||
version is not actually present locally. Or if `git-annex fsck` on it says
|
||||
its fixing the location logs, that would tell us something happened that
|
||||
got the location tracking out of sync with reality.
|
||||
|
||||
So possibly there's an issue that could be tracked down regarding the state
|
||||
of that file. But in either case, git-annex doesn't know it has a local
|
||||
copy of the file, so `copy --from --to` could not use it.
|
||||
|
||||
----
|
||||
|
||||
But: `copy --from --to` does in fact have an interesting bug:
|
||||
|
||||
joey@darkstar:~/tmp/bench/r2>git-annex whereis foo
|
||||
whereis foo (2 copies)
|
||||
22dfa446-7482-4c0a-92c9-70db793859fb -- joey@darkstar:~/tmp/bench/r [origin]
|
||||
8a504049-2c22-4baa-9a16-218e9561608b -- joey@darkstar:~/tmp/bench/r2 [here]
|
||||
ok
|
||||
joey@darkstar:~/tmp/bench/r2>git-annex copy foo --from origin --to r3
|
||||
joey@darkstar:~/tmp/bench/r2>
|
||||
|
||||
So the file content being present locally prevents it sending it to the remote! This needs to get fixed.
|
||||
|
||||
Hmm: In the corresponding case of `git-annex move --from --to`, it does not
|
||||
behave that way.
|
||||
|
||||
----
|
||||
|
||||
As far as what the behavior ought to be when a file is present locally but not on the --from remote,
|
||||
the documentation does say:
|
||||
|
||||
--from=remote
|
||||
|
||||
Copy the content of files from the specified remote to the local repository.
|
||||
|
||||
Any files that are not available on the remote will be silently skipped.
|
||||
|
||||
So it is behaving as documented. I can think of two reasons why that
|
||||
documented behavior makes some sense:
|
||||
|
||||
* The user may be intending to only copy files --to that are present in --from.
|
||||
The local repo may have a lot of files they do not want to populate --to.
|
||||
(For example, perhaps the goal is to make a replica of the --from
|
||||
repository.)
|
||||
With that said, the user could do `git-annex copy --from foo --to bar --in foo`
|
||||
to explicitly only act on files that are present in it.
|
||||
* Performance. Needing to check if there is a local copy when there is no
|
||||
remote copy would be a little extra work. Likely not enough to be
|
||||
significant though.
|
||||
"""]]
|
Loading…
Reference in a new issue