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-01-24 11:39:43 -04:00
commit 639d19dbd1
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 68 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

34
doc/bugs/dead_clone_easily_dead_when_not_intended_.mdwn Normal file
View file

@ -0,0 +1,34 @@
### Please describe the problem.
Current syntax of `dead` online at git annex dead [repository ...] [--key somekey ...] says
`git annex dead [repository ...] [--key somekey ...]`
which is also incorrect rendering I think since it is
```
[d31548v@ndoli tmp]$ git annex dead --help
git-annex dead - hide a lost repository or key
Usage: git-annex dead [[REPOSITORY ...] | [--key KEY]]
```
so it is EITHER to announce REPOSITORY or a KEY.
Naive/new/quick users, since many annex commands take file paths as arguments could provide `dead` with both - repository and local paths, e.g. `git annex dead here */*.nii.gz` or alike. But then annex proceeds with marking `here` dead while then erroring out on paths:
```shell
(datalad-dev) [d78092t@ndoli 1080_wasabi]$ git-annex dead here sub-SID000743/ses-01/func/*.nii
dead here (recording state in git...)
ok
git-annex: there is no available git remote named "sub-SID000743/ses-01/func/sub-SID000743_ses-01_task-hyperalignment_acq-mb8_run-04_bold.nii"
```
which is correct/expected behavior given the fact that if RTFM then those are to be taken as repositories.
But I wondered if may be `git annex` could/should become more "protective" and fail early if any of provided repositories is "not available"?
[[!meta author=yoh]]
[[!tag projects/openneuro]]

10
doc/git-annex-dead/comment_1_704469f0deb075d0b3c70c73708cd456._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="comment 1"
date="2025-01-23T15:53:39Z"
content="""
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`?
"""]]

8
doc/git-annex-dead/comment_2_4da905b6b8c0c0ba31f4379bf6d940e0._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="comment 2"
date="2025-01-23T21:33:25Z"
content="""
d'oh -- it is `git annex semitrust here` to return the \"trust\" into a dead beast ;)
"""]]

16
doc/git-annex-whereused/comment_4_2270f72a453d8a75a2e050c82561e4ae._comment Normal file
View file

@ -0,0 +1,16 @@
[[!comment format=mdwn
username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
nickname="beryllium"
avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
subject="comment 4"
date="2025-01-24T08:04:27Z"
content="""
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)
"""]]