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

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

Browse source
This commit is contained in:
Joey Hess 2023-12-26 15:41:03 -04:00
commit 766dfc794a
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 69 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
doc/bugs/__96__git_annex_info__96___hangs_with_git_special_remote/comment_7_9104e12c57bc47cfd0a6c109ad085de1._comment Normal file
View file

@ -0,0 +1,21 @@
[[!comment format=mdwn
username="Atemu"
avatar="http://cdn.libravatar.org/avatar/86b8c2d893dfdf2146e1bbb8ac4165fb"
subject="comment 7"
date="2023-12-25T13:03:50Z"
content="""
To explain my rationale a bit more, I use `git-annex info` for three purposes (descending frequency):
1. Overview of repos and trust level (like `git remote`)
2. Query metadata of files/keys (size, repo/group presence)
3. Query metadata of individual repos (size, trust)
AFAICT, none of these actually interact with remote repositories in any way; they gather information from the local `git-annex` branch and present it in a digestible format. (Apart from the presence check functionality in question of course.) I'd expect these to run these as fast as the CPU and disk allow without any possible interference by the network.
Commands like `sync`, `copy` or get must obviously interact with other repositories; it's their primary or even sole purpose. When remote repos are present, I'd fully expect network usage with these and, equally important, timing dependence.
(Though I too would love to see an offline flag for these commands like Yann suggested; i.e. `git annex copy --auto --offline` only copying from and to locally available repos.)
I would not expect `info` to have to open any network connections to do its job however; all of the data should be present in the `git-annex` branch afterall. Repo presence is a practical and desirable feature but I wouldn't expect it to be updated on every invocation of `info` and in fact it isn't: When I unmount a repo and run `info` again, git-annex still thinks its present. Actually not even a `sync` will update that; I'm unsure whether it's even possible to do so?
I think I'd prefer an explicit `git annex info --fetch` command (or perhaps even a new sub command) which runs the repo presence check from scratch for all repos or a specific repo. This stops the regular `info` command from requiring any networking whatsoever and provides confidence that remotes are actually present when claimed as such after you run it.
"""]]

23
doc/forum/Don__39__t_copy_files_to_exporttree__61__no_remote/comment_4_c3d9048668596f6be3975026ec1debc1._comment Normal file
View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="Atemu"
avatar="http://cdn.libravatar.org/avatar/86b8c2d893dfdf2146e1bbb8ac4165fb"
subject="comment 4"
date="2023-12-25T12:21:58Z"
content="""
The remote's `annex-tracking-branch` includes the sub-directory in my setup.
I did not mean that it ignores exporttree and actually exports files, it ignores it insofar that it attempts to copy to the remote but then fails because `exporttree=no`. Tonnes of:
```
copy Filename (to paperless...)
remote is configured with importtree=yes and without exporttree=yes; cannot modify content stored on it
failed
```
It shouldn't even attempt to do that, it will never work.
Some new info: After updating my NAS to NixOS 23.11, it is now also affected while it wasn't before on 23.05.
Good: 10.20230407
Bad: 10.20230926
"""]]

25
doc/todo/info__58___allow_file_matching_options_for_all_keys/comment_2_2d0a6abd5be8afce677eeea575aae548._comment Normal file
View file

@ -0,0 +1,25 @@
[[!comment format=mdwn
username="Atemu"
avatar="http://cdn.libravatar.org/avatar/86b8c2d893dfdf2146e1bbb8ac4165fb"
subject="comment 2"
date="2023-12-25T13:37:58Z"
content="""
Sorry for the late reply but this somehow didn't reach me.
I just tried querying some basic stats such as `--not --copies 2` and running that with `git annex info .` works as expected:
```
directory: .
local annex keys: 0
local annex size: 0 bytes
annexed files in working tree: 0
size of annexed files in working tree: 0 bytes
```
`git annex info --not --copies 2` confusingly displays the repo overview and then starts calculating first local and then \"annexed files in working tree\" keys. It does not show the useful repo overview which displays how many matched keys are in each repo that has at least one however.
With that filter, `git annex info .` takes 15s in my case while `git annex info` takes 20s, likely due to the local key lookup. Trying to avoid the local lookup using `--fast` unfortunately also avoids the working tree lookup; outputting the same info as `git annex info --fast` without any filters which doesn't seem very useful.
Does the latter really query all keys however? It appears to me that it's the same as querying `.`. I have nearly 100 unused keys in that repo but both info commands show the same amount.
"""]]