Recent comments posted to this site:

Hi Joe,

I have been using git-annex since several years now and am really happy with it.

But the addition of git-lfs support was, in my humble opinion, an extraordinary leap forward! After gitlab ceased support in favour of lfs and with the advent of lfs in github, annex-integration with widespread used collaborative git-platforms was not very straight-forward anymore. And so it became harder to justify or promote it's use in my institute or other organizations I work for. This has change now again for the better!

So thank you very much for all the hard work and regarding the daunting speed with which new developments and features (version 8 already!) arrive here: Please take good care and do not overstrain yourself.

Kind regards,

Jörn

Comment by jkrenzer Thu Dec 5 12:10:47 2019
"I synced to all remotes and dropped everything in 'here'" -- git-annex-unused "Checks the annex" for the unused contents (unless --from=repository is used), so if you dropped everything in here, there's nothing to find. But it seems from du results that contents wasn't actually dropped? git-annex-whereis tells where git-annex thinks contents is.
Comment by Ilya_Shlyakhter Mon Dec 2 16:58:25 2019

"May I delete them" -- git-annex-drop --force may be safer, as it also updates location tracking. You might also want to git-annex-dead the dropped keys to prevent git-annex-fsck from complaining about lost contents.

Re: why git-annex-unused isn't finding the unused contents, try running it with --used-refspec=+HEAD, and make sure annex.used-refspec git config is not set. Note that this will mark as unused any annexed contents not referenced from the latest tree of the HEAD branch, e.g. annexed files that were removed in some older commit.

Comment by Ilya_Shlyakhter Mon Dec 2 16:48:47 2019
Did you commit after git-migrate? Does the worktree have any uncommitted changes?
Comment by Ilya_Shlyakhter Mon Dec 2 16:02:47 2019
I forgot to tell that after migrating I synced to all remotes and dropped everything in 'here', that's why I was expecting no more objects locally.
Comment by atrent Mon Dec 2 08:03:01 2019
the "lost" objects are all SHA256E (with the "E")
Comment by atrent Mon Dec 2 07:29:06 2019

I recently migrated an annex to SHA256 (without "E") and I'm now trying to clean the repo from unused data. I have a strange situation: there are 62G of unused objects:

$ du -ks .git/annex/objects/
64334024    .git/annex/objects/

but 'git annex unused' gives me only:

$ git annex unused
unused ...
Some annexed data is no longer used by any files:
NUMBER  KEY
1       SHA256E-s27--32efec98dc9e05442fc2385bb85d855a8c7824c68abd4ab5bf55a4dfe412b334.pdf
(To see where data was previously used, try: git log --stat --no-textconv -S'KEY')
To remove unwanted data: git-annex dropunused NUMBER
ok

I've checked (through a small shell script) that none of the object is in fact referenced by any symlink...

May I delete them? Shall I do some other checking/fscking/repairing?

Thank you

Comment by atrent Mon Dec 2 07:26:41 2019

Getting the following error on runnning zypper in git-annex

Loading repository data...
Reading installed packages...
Package 'git-annex' not found.

I am running openSUSE for WSL with the following info

NAME="openSUSE Leap"
VERSION="15.1 "
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.1"
PRETTY_NAME="openSUSE Leap 15.1"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.1"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
Comment by nangal.vivek Sun Dec 1 17:04:53 2019
I'm git-annex-migrating (to SHA256) now, thank you for all suggestions!
Comment by atrent Sat Nov 30 22:30:06 2019

P.S. Re: hardlinking identical files -- git-annex keeps track of inodes where contents is stored, so deleting a file might make that info stale. Also, dropping one key will drop another key's contents without updating location tracking info. And dropping then getting files would lead to two separate copies again. So I wouldn't recommend that.

See also local caching of annexed files.

Comment by Ilya_Shlyakhter Sat Nov 30 21:36:38 2019