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

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

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.

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.
"""]]