I don't know if this is expected behaviour, but for some files I imported from an importtree, when I use git-annex whereused --key with the correct key, nothing is shown unless I also add --historical

And then I am shown the importtree branch information. It doesn't seem to make sense to me. The file is definitely present, and git-annex whereis confirms this, as does git-annex lock/unlock

Willing to add more context if this is a little too vague

Shaddy Baddah (beryllium at shaddybaddah dot name)

d'oh -- it is git annex semitrust here to return the "trust" into a dead beast

is there git annex undead to easily mitigate users doing what they should have not done?

Would it be sufficient to just remove the corresponding X line from trust.log?

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.

Thank you very much, I can confirm that it works with git-annex 10.20250116-g8d80b07f5aee368579e04b2acba56a8821eeaab0. 👍

The difficulty here is that it needs to come up with the name of a corresponding remote tracking branch to update. It could use "myexport/synced/main" for that. But, setting annex-tracking-branch to a remote ref like "origin/main" is not supported, and it would not be good if it allowed it and used a tracking branch with a name like "myexport/origin/main".

And well, we know that "synced/main" is not a remote ref, but "$foo/main" generally may or may not be one.

So, I think to support this, it would have only allow using "$foo/main" when the ref "refs/remotes/$foo/main" does not exist. I've implemented that.

This could be detected and handled directly by git annex repair or the git annex assistant daemon.
I unfortunately have no Haskell knowledge and the barrier to entry seems to big for me to contribute right now.

Hi, I have stumbled upon this specific bug today too.

I use git-annex: 10.20240927-3 (latest on Manjaro) with git-remote-gcrypt: 1.5-1 (latest at the time) and I now have the same issue.

$ git push <remote> master 
gcrypt: Decrypting manifest
gpg: Signature made jeu. 16 janv. 2025 18:56:55 CET
gpg:                using EDDSA key ***
gpg: Good signature from "*** <***>" [ultimate]
gcrypt: Due to a longstanding bug, this push implicitly has --force.
gcrypt: Consider explicitly passing --force, and setting
gcrypt: gcrypt's require-explicit-force-push git config key.
gcrypt: Repacking remote <remote>, ...
gcrypt: Packfile *** does not match digest!
fatal: early EOF
error: failed to push some refs to 'gcrypt::ssh://librarian@<ip>:<port>/~/library.git'

I tried to reproduce the issue and it seems that it is easy to force this to happen if - you have a git annex assistant running in the annex
- copy a large directory (I used a .flac music album, 2.1Gi) to the annex so that it is uploaded to the gcrypt remote automatically
- issue a git annex sync --content while the assistant is trying to upload the content to the remote

I found myself wanting this today, wondering if a git-annex move --unused would fit into the destination.

I think it would make sense to add it to git-annex unused. Making git-annex info output vary depending on when and how unused was run last I don't like.

Implemented .git/hooks/pre-init-annex (and alternatively git config annex.pre-init-command)

Note that this is also run before automatic initialization.