mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2025-03-17 14:33:11 -04:00
commit f775c9643f
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 69 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

39
doc/bugs/fsck_complains_about_requires_of_dead_repos.mdwn Normal file
View file

@ -0,0 +1,39 @@
### Please describe the problem.
When running an fsck, I just had git-annex tell me that required content was missing from a bunch of repos that comprise my cold storage which makes sense but it also listed dead repos in the listing. Those repos are still in the group and still have `groupwanted` as the required setting.
Dead drives should never be considered requiring or wanting content, even if they're still configured as such. (Or holding content for that matter but I hope that part works.)
### What steps will reproduce the problem?
1. Have dead repos that require content
2. Have alive repos that require the same content (unsure if required)
3. `git annex fsck`
### What version of git-annex are you using? On what operating system?
```
git-annex version: 10.20241202
build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Servant Feeds Testsuite S3 WebDAV
dependency versions: aws-0.24.1 bloomfilter-2.0.1.2 crypton-0.34 DAV-1.3.4 feed-1.3.2.1 ghc-9.6.6 http-client-0.7.17 persistent-sqlite-2.13.3.0 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL GITBUNDLE GITMANIFEST VURL X*
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg rclone hook external
operating system: linux x86_64
supported repository versions: 8 9 10
upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
local repository version: 10
```
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
# End of transcript or log.
"""]]
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Best invention since sliced bread.

3
doc/forum/Does___96__fsck_--more__96___imply___96__--incremental__96____63__.mdwn Normal file
View file

@ -0,0 +1,3 @@
The man page is not too clear on this and I noticed that it's not possible to pass both flags at once.
Does interrupting `fsck --more` lose the progress made since the initial incremental fsck?

11
doc/todo/Incremental_fsck_by_default.mdwn Normal file
View file

@ -0,0 +1,11 @@
Whenever I do an fsck, it's always annoyed me that you have to think of adding `--incremental` and then also think about whether an incremental fsck was started and interrupted before which would then require `--more` instead.
Forgetting to add `--incremental` can leave you in a pickle when you later find out that you need to interrupt the fsck, losing all progress.
I've found myself wondering whether there'd ever be a case where I'd not want an fsck to be resumeable. Could git-annex not just simply always store that information and leave it up to the next fsck execution to decide whether to use it or not?
I actually don't see much reason to not make use of an incremental fsck either unless it's *really* old but I find this a lot more debatable than at least storing fsck state on each run.
On that note: There also does not appear to be a documented method to figure out whether a fsck was interrupted before. You could infer existence and date from the annex internal directory structure but seeing the progress requires manual sql.
Perhaps there could be a `fsck --info` flag for showing both interrupted fsck progress and perhaps also the progress of the current fsck.

12
doc/todo/compute_special_remote/comment_23_11e2e14ab20856b005793e80e79d2382._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="msz"
avatar="http://cdn.libravatar.org/avatar/6e8b88e7c70d86f4cfd27d450958aed4"
subject="comment 23"
date="2025-03-12T19:44:23Z"
content="""
@joey:
> I do hope I'm not closing off the design space from such differences by dropping a compute special remote right into git-annex. But I also expect that having a standard and easy way for at least simple computations will lead to a lot of contributions as others use it.
I think it's excellent to have something like this in git-annex. I didn't have the opportunity to try it out yet, but I am definitely looking forward to seeing how things can work in practice and comparing the implementations.
"""]]

4
doc/users/msz.mdwn Normal file
View file

@ -0,0 +1,4 @@
Michał Szczepanik
[@doktorpanik@masto.ai](https://masto.ai/@doktorpanik)
Postdoc @ [Psychoinformatics Group](https://psychoinformatics.de/), INM-7, Forschungszentrum Jülich