response
This commit is contained in:
parent
f41054b108
commit
d46504e51e
1 changed files with 24 additions and 0 deletions
|
@ -0,0 +1,24 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2025-01-22T20:43:32Z"
|
||||
content="""
|
||||
If the laptop has not pulled from the server since those files were sent to
|
||||
it, it does not know the server contains the files yet. So it will try to
|
||||
send them again. Normally this won't result in the same content being
|
||||
actually sent again, instead for each file it will check if the file is in
|
||||
the server yet, and when it sees it is, it won't send it again.
|
||||
|
||||
My first guess is that just the network overhead of doing those checks is
|
||||
what "fills the upstream".
|
||||
|
||||
It is possible that it's actually re-uploading files that the server
|
||||
already has, without checking it first, which will result in the server
|
||||
accepting the upload and then throwing it away, since it already has the content.
|
||||
This can happen eg, if the same file is being sent into a repository from
|
||||
two other repositories at the same time. But I don't know of any common
|
||||
situations where it happens.
|
||||
|
||||
So, if you're sure it's doing that, please provide details about what exact
|
||||
git-annex commands you're running that are causing it to do that.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue