merge in doc changes from master
This commit is contained in:
Joey Hess
parent
9e4314de76
commit
cbb6df35aa
38 changed files with 1136 additions and 27 deletions
|
|
@ -0,0 +1,8 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="nobodyinperson"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
|
||||||
|
subject="Exporting a synced/* branch works now! 🥳"
|
||||||
|
date="2025-01-21T18:30:50Z"
|
||||||
|
content="""
|
||||||
|
Thank you very much, I can confirm that it works with git-annex 10.20250116-g8d80b07f5aee368579e04b2acba56a8821eeaab0. 👍
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,65 @@
|
||||||
|
### Please describe the problem.
|
||||||
|
|
||||||
|
I have in my mailbox
|
||||||
|
|
||||||
|
```
|
||||||
|
80 T Jan 26 GitHub Actions *-3.6* (3.7K/0) datalad/git-annex daily summary: 4 FAILED, 8 INCOMPLETE, 1 PASSED, 3 ABSENT
|
||||||
|
206 N T Jan 25 GitHub Actions *-3.8* (3.7K/0) datalad/git-annex daily summary: 4 FAILED, 8 INCOMPLETE, 1 PASSED, 3 ABSENT
|
||||||
|
357 T Jan 24 GitHub Actions *-4.4* (6.3K/0) datalad/git-annex daily summary: 12 FAILED, 8 INCOMPLETE, 1 PASSED, 3 ABSENT
|
||||||
|
1279 T Jan 23 GitHub Actions *-4.5* (3.7K/0) datalad/git-annex daily summary: 5 FAILED, 8 INCOMPLETE, 3 ABSENT
|
||||||
|
1715 T Jan 22 GitHub Actions *-5.0* (3.7K/0) datalad/git-annex daily summary: 5 FAILED, 8 INCOMPLETE, 3 ABSENT 2335 T Jan 21 GitHub Actions *-3.9* (3.7K/0) datalad/git-annex daily summary: 5 FAILED, 8 INCOMPLETE, 3 ABSENT
|
||||||
|
2656 T Jan 20 GitHub Actions *-4.3* (6.8K/0) datalad/git-annex daily summary: 28 PASSED, 2 ABSENT
|
||||||
|
2862 T Jan 19 GitHub Actions *-5.0* (6.8K/0) datalad/git-annex daily summary: 28 PASSED, 2 ABSENT
|
||||||
|
```
|
||||||
|
|
||||||
|
and looking at the [latest ubuntu build logs](https://github.com/datalad/git-annex/actions/runs/12970824274/job/36176536041) I see
|
||||||
|
|
||||||
|
```
|
||||||
|
I: the tail of the log
|
||||||
|
|
||||||
|
Build/LinuxMkLibs.hs:101:17: error:
|
||||||
|
Variable not in scope:
|
||||||
|
createDirectoryIfMissing :: Bool -> [Char] -> IO a3
|
||||||
|
|
|
||||||
|
101 | createDirectoryIfMissing True (top ++ libdir </> takeDirectory d)
|
||||||
|
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
Build/LinuxMkLibs.hs:149:9: error:
|
||||||
|
Variable not in scope:
|
||||||
|
createDirectoryIfMissing :: Bool -> FilePath -> IO a2
|
||||||
|
|
|
||||||
|
149 | createDirectoryIfMissing True (top </> shimdir)
|
||||||
|
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
Build/LinuxMkLibs.hs:150:9: error:
|
||||||
|
Variable not in scope:
|
||||||
|
createDirectoryIfMissing :: Bool -> FilePath -> IO a1
|
||||||
|
|
|
||||||
|
150 | createDirectoryIfMissing True (top </> exedir)
|
||||||
|
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
Build/LinuxMkLibs.hs:160:19: error:
|
||||||
|
* Variable not in scope:
|
||||||
|
renameFile :: FilePath -> FilePath -> IO ()
|
||||||
|
* Perhaps you meant `readFile' (imported from Prelude)
|
||||||
|
|
|
||||||
|
160 | , renameFile exe exedest
|
||||||
|
| ^^^^^^^^^^
|
||||||
|
|
||||||
|
Build/LinuxMkLibs.hs:165:18: error:
|
||||||
|
Variable not in scope: doesFileExist :: FilePath -> IO Bool
|
||||||
|
|
|
||||||
|
165 | unlessM (doesFileExist (top </> exelink)) $
|
||||||
|
| ^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
Build/LinuxMkLibs.hs:181:9: error:
|
||||||
|
Variable not in scope:
|
||||||
|
createDirectoryIfMissing :: Bool -> FilePath -> IO a0
|
||||||
|
|
|
||||||
|
181 | createDirectoryIfMissing True destdir
|
||||||
|
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
make[3]: *** [Makefile:156: Build/Standalone] Error 1
|
||||||
|
make[3]: Leaving directory '/home/runner/work/git-annex/git-annex/git-annex-source'
|
||||||
|
make[2]: *** [Makefile:164: linuxstandalone] Error 2
|
||||||
|
```
|
||||||
|
|
||||||
|
|
@ -4,13 +4,13 @@ I have a pretty big repository with around 300 000 files in the workdir of a bra
|
||||||
I wanted to unlock all those files from that branch on a machine, so I tried to use git-annex-adjust --unlock.
|
I wanted to unlock all those files from that branch on a machine, so I tried to use git-annex-adjust --unlock.
|
||||||
Sadly, the command do not seems to finish, ever.
|
Sadly, the command do not seems to finish, ever.
|
||||||
|
|
||||||
Executing the command with debug from a clone(to avoid interacting with the broken index from the first), it seems to deadlock after executing between 10000 and 20000 "thawing" processes when executing the filter-process logic over the files in the worktree.
|
Executing the command with the debug flag from a clone(to avoid interacting with the broken index from the first), it seems to deadlock after executing 10240 completed processes for the filter-process logic over the files in the worktree, which happens to match the annex.queuesize configuration value in use in those repositories.
|
||||||
The problem seems to be reproducible with any repository with a lot of files in the worktree as far as I can tell, independant of file size.
|
The problem seems to be reproducible with any repository with more than the aforementioned count of files in the worktree as far as I can tell, independant of file size.
|
||||||
|
|
||||||
The deadlock described makes higher-level commands like git annex sync also block indefinitely when checkout-ing the unlocked branch for any reason.
|
The deadlock described makes higher-level commands like git annex sync also block indefinitely when checkout-ing the unlocked branch for any reason in these kinds of unlocked repository du to implcit call to the deadlocking git-annex smudge code.
|
||||||
Also, because the filtering is not completely applied, the index is pretty scrambled, its easier to clone the repo and move the annex than fix it, for me at least.
|
Also, because the filtering is not completely applied, the index is pretty scrambled, its easier to clone the repo and move the annex than fix it, for me at least.
|
||||||
|
|
||||||
I call the behavior "deadlock" due to the absence of debug log output and low cpu usage on the process when in that state. This seems to indicate some kind of multiprocessing deadlock to me.
|
I call the behavior "deadlock" due to the absence of debug log output after the 10240 th process and 0% cpu usage on the remaining git and git-annex processes when the bug happens. This seems to indicate some kind of multiprocessing deadlock to me.
|
||||||
|
|
||||||
### What steps will reproduce the problem?
|
### What steps will reproduce the problem?
|
||||||
|
|
||||||
|
|
@ -27,10 +27,13 @@ Here is a minimum set of bash commands that generate the deadlock on my end:
|
||||||
git annex add
|
git annex add
|
||||||
git commit -m "add all empty files"
|
git commit -m "add all empty files"
|
||||||
|
|
||||||
# This will get stuck after around ~10000-20000 processes from Utility.Process in the debug log while the git annex thaws files into unlocked files
|
# This will get stuck after 10240 processes from Utility.Process completed in the debug log while git annex thaws files into unlocked files
|
||||||
# The deadlock seems to happens after outputing the start of a new thawing, ctrl-c seems to be the only end state for this
|
# The deadlock seems to happens after outputing the start of the last thawing in the queue, ctrl-c seems to be the only end state for this
|
||||||
git annex adjust --unlock --debug
|
git annex adjust --unlock --debug 2> ~/unlock-log
|
||||||
|
# Ctrl-c the command above once the debug output cease to output new lines without exiting.
|
||||||
|
|
||||||
|
# This commands output the number of processes ran for the command above, which is 10240 for me
|
||||||
|
cat ~/unlock-log | grep Perms | wc -l
|
||||||
|
|
||||||
### What version of git-annex are you using? On what operating system?
|
### What version of git-annex are you using? On what operating system?
|
||||||
|
|
||||||
|
|
@ -64,14 +67,15 @@ Debian Bookworm [Compiled via "building from source on Debian"]
|
||||||
|
|
||||||
### Please provide any additional information below.
|
### Please provide any additional information below.
|
||||||
|
|
||||||
Excerpt of the last lines from the huge debug log:
|
Excerpt of the last lines from the huge debug log from the git annex adjust above:
|
||||||
|
|
||||||
[2025-01-16 23:30:27.913022014] (Utility.Process) process [493397] done ExitSuccess
|
[2025-01-16 23:30:27.913022014] (Utility.Process) process [493397] done ExitSuccess
|
||||||
[2025-01-16 23:30:27.91309169] (Annex.Perms) thawing content .git/annex/othertmp/BKQKGR.0/BKQKGR
|
[2025-01-16 23:30:27.91309169] (Annex.Perms) thawing content .git/annex/othertmp/BKQKGR.0/BKQKGR
|
||||||
|
|
||||||
Given the huge debug log produced, it may be easier to reproduce the bug to have it than copying it here. If wanted, I can generate one as required.
|
Given the huge debug log produced for this bug, it may be easier to reproduce the bug to have it than copying it here. If wanted, I can generate one as required with the process documented in for the bug repoduction above.
|
||||||
|
|
||||||
Repeatedly calling this(and ctrl-c it when it inevitably get stuck) seems to eventually unlock the files, but its not really a valid solution in my case.
|
|
||||||
|
Repeatedly calling this(and ctrl-c it when it inevitably get stuck) seems to eventually unlock the files ion batches of 10240, but its not really a valid solution in my case.
|
||||||
|
|
||||||
git annex smudge --update --debug
|
git annex smudge --update --debug
|
||||||
|
|
||||||
|
|
|
||||||
34
doc/bugs/dead_clone_easily_dead_when_not_intended_.mdwn
Normal file
34
doc/bugs/dead_clone_easily_dead_when_not_intended_.mdwn
Normal 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]]
|
||||||
362
doc/bugs/git-remote-annex_for_directory_on_macOS.mdwn
Normal file
362
doc/bugs/git-remote-annex_for_directory_on_macOS.mdwn
Normal file
|
|
@ -0,0 +1,362 @@
|
||||||
|
### Please describe the problem.
|
||||||
|
Running `git-annex enableremote local1 --with-url` for directory special remote `local` fails on macOS.
|
||||||
|
|
||||||
|
Trying to sync to directory special remote configured manually as git-remote-annex fails on macOS.
|
||||||
|
|
||||||
|
### What steps will reproduce the problem?
|
||||||
|
[[!format sh """
|
||||||
|
% pwd
|
||||||
|
/tmp/git-annex-testing
|
||||||
|
% mkdir repo
|
||||||
|
% cd repo
|
||||||
|
% git init
|
||||||
|
% git annex init
|
||||||
|
% echo "file a" > a.txt
|
||||||
|
% echo "file b" > b.txt
|
||||||
|
% git annex add a.txt
|
||||||
|
% git annex add b.txt
|
||||||
|
% git commit -m "added files"
|
||||||
|
% git annex info
|
||||||
|
...
|
||||||
|
local annex keys: 2
|
||||||
|
local annex size: 14 bytes
|
||||||
|
annexed files in working tree: 2
|
||||||
|
..
|
||||||
|
% mkdir ../specialdirectoryremote
|
||||||
|
% git annex initremote local1 type=directory directory=/tmp/git-annex-testing/specialdirectoryremote encryption=none
|
||||||
|
initremote local1 ok
|
||||||
|
(recording state in git...)
|
||||||
|
% git annex copy --to=local1
|
||||||
|
% git annex info local1
|
||||||
|
uuid: 7d7560cd-2e80-489d-af4a-ec23b9b9abb7
|
||||||
|
description: [local1]
|
||||||
|
trust: semitrusted
|
||||||
|
remote: local1
|
||||||
|
cost: 100.0
|
||||||
|
type: directory
|
||||||
|
available: true
|
||||||
|
directory: /tmp/git-annex-testing/specialdirectoryremote
|
||||||
|
encryption: none
|
||||||
|
chunking: none
|
||||||
|
remote annex keys: 2
|
||||||
|
remote annex size: 14 bytes
|
||||||
|
% git-annex enableremote local1 --with-url
|
||||||
|
enableremote local1
|
||||||
|
git-annex: Specify directory=
|
||||||
|
failed
|
||||||
|
enableremote: 1 failed
|
||||||
|
"""]]
|
||||||
|
|
||||||
|
|
||||||
|
### What version of git-annex are you using? On what operating system?
|
||||||
|
[[!format sh """
|
||||||
|
% git --version
|
||||||
|
git version 2.48.0
|
||||||
|
% git-annex version
|
||||||
|
git-annex version: 10.20250103-gbd5d7e936d15abc1376f64ea9a124bba0b6e2d11
|
||||||
|
build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Servant Benchmark Feeds Testsuite S3 WebDAV
|
||||||
|
dependency versions: aws-0.24.3 bloomfilter-2.0.1.2 crypton-1.0.1 DAV-1.3.4 feed-1.3.2.1 ghc-9.8.4 http-client-0.7.18 persistent-sqlite-2.13.3.0 torrent-10000.1.3 uuid-1.3.16 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: darwin 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
|
||||||
|
% sw_vers
|
||||||
|
ProductName: macOS
|
||||||
|
ProductVersion: 12.6.3
|
||||||
|
BuildVersion: 21G419
|
||||||
|
% uname -a
|
||||||
|
Darwin bumblebee.local 21.6.0 Darwin Kernel Version 21.6.0: Mon Dec 19 20:46:01 PST 2022; root:xnu-8020.240.18~2/RELEASE_ARM64_T8101 arm64
|
||||||
|
%
|
||||||
|
"""]]
|
||||||
|
|
||||||
|
### Please provide any additional information below.
|
||||||
|
|
||||||
|
[[!format sh """
|
||||||
|
% git --version
|
||||||
|
git version 2.48.0
|
||||||
|
% git-annex version
|
||||||
|
git-annex version: 10.20250103-gbd5d7e936d15abc1376f64ea9a124bba0b6e2d11
|
||||||
|
build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Servant Benchmark Feeds Testsuite S3 WebDAV
|
||||||
|
dependency versions: aws-0.24.3 bloomfilter-2.0.1.2 crypton-1.0.1 DAV-1.3.4 feed-1.3.2.1 ghc-9.8.4 http-client-0.7.18 persistent-sqlite-2.13.3.0 torrent-10000.1.3 uuid-1.3.16 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: darwin 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
|
||||||
|
% sw_vers
|
||||||
|
ProductName: macOS
|
||||||
|
ProductVersion: 12.6.3
|
||||||
|
BuildVersion: 21G419
|
||||||
|
% uname -a
|
||||||
|
Darwin bumblebee.local 21.6.0 Darwin Kernel Version 21.6.0: Mon Dec 19 20:46:01 PST 2022; root:xnu-8020.240.18~2/RELEASE_ARM64_T8101 arm64
|
||||||
|
%
|
||||||
|
|
||||||
|
|
||||||
|
% pwd
|
||||||
|
/tmp/git-annex-testing
|
||||||
|
% mkdir repo
|
||||||
|
% cd repo
|
||||||
|
% git init
|
||||||
|
% git annex init
|
||||||
|
% echo "file a" > a.txt
|
||||||
|
% echo "file b" > b.txt
|
||||||
|
% git annex add a.txt
|
||||||
|
% git annex add b.txt
|
||||||
|
% git commit -m "added files"
|
||||||
|
% git annex info
|
||||||
|
...
|
||||||
|
local annex keys: 2
|
||||||
|
local annex size: 14 bytes
|
||||||
|
annexed files in working tree: 2
|
||||||
|
..
|
||||||
|
% mkdir ../specialdirectoryremote
|
||||||
|
% git annex initremote local1 type=directory directory=/tmp/git-annex-testing/specialdirectoryremote encryption=none
|
||||||
|
initremote local1 ok
|
||||||
|
(recording state in git...)
|
||||||
|
% git annex copy --to=local1
|
||||||
|
% git annex info local1
|
||||||
|
uuid: 7d7560cd-2e80-489d-af4a-ec23b9b9abb7
|
||||||
|
description: [local1]
|
||||||
|
trust: semitrusted
|
||||||
|
remote: local1
|
||||||
|
cost: 100.0
|
||||||
|
type: directory
|
||||||
|
available: true
|
||||||
|
directory: /tmp/git-annex-testing/specialdirectoryremote
|
||||||
|
encryption: none
|
||||||
|
chunking: none
|
||||||
|
remote annex keys: 2
|
||||||
|
remote annex size: 14 bytes
|
||||||
|
% git-annex enableremote local1 --with-url
|
||||||
|
enableremote local1
|
||||||
|
git-annex: Specify directory=
|
||||||
|
failed
|
||||||
|
enableremote: 1 failed
|
||||||
|
|
||||||
|
% git config set annex.debug true
|
||||||
|
% git-annex enableremote local1 --with-url
|
||||||
|
[2025-01-28 12:38:26.198647] (Utility.Process) process [13595] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
|
||||||
|
[2025-01-28 12:38:26.206976] (Utility.Process) process [13595] done ExitSuccess
|
||||||
|
[2025-01-28 12:38:26.209633] (Utility.Process) process [13596] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
|
||||||
|
[2025-01-28 12:38:26.216084] (Utility.Process) process [13596] done ExitSuccess
|
||||||
|
[2025-01-28 12:38:26.220051] (Utility.Process) process [13597] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
|
||||||
|
enableremote local1
|
||||||
|
git-annex: Specify directory=
|
||||||
|
failed
|
||||||
|
[2025-01-28 12:38:26.228828] (Utility.Process) process [13597] done ExitSuccess
|
||||||
|
enableremote: 1 failed
|
||||||
|
%
|
||||||
|
|
||||||
|
|
||||||
|
% git config remote.local1.url annex::
|
||||||
|
% git config remote.local1.fetch '+refs/heads/*:refs/remotes/foo/*'
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
% git push --set-upstream local1 master
|
||||||
|
[2025-01-28 12:45:05.935101] (Utility.Process) process [20178] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
|
||||||
|
[2025-01-28 12:45:05.941251] (Utility.Process) process [20178] done ExitSuccess
|
||||||
|
[2025-01-28 12:45:05.943896] (Utility.Process) process [20179] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
|
||||||
|
[2025-01-28 12:45:05.950867] (Utility.Process) process [20179] done ExitSuccess
|
||||||
|
[2025-01-28 12:45:05.95425] (Utility.Process) process [20180] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
|
||||||
|
Full remote url: annex::7d7560cd-2e80-489d-af4a-ec23b9b9abb7?encryption=none&type=directory
|
||||||
|
[2025-01-28 12:45:05.96577] (Utility.Process) process [20181] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","for-each-ref","refs/namespaces/git-remote-annex/7d7560cd-2e80-489d-af4a-ec23b9b9abb7/","--format=%(objectname) %(refname)"]
|
||||||
|
[2025-01-28 12:45:05.973785] (Utility.Process) process [20181] done ExitSuccess
|
||||||
|
[2025-01-28 12:45:05.976602] (Utility.Process) process [20182] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
|
||||||
|
[2025-01-28 12:45:05.983816] (Utility.Process) process [20182] done ExitSuccess
|
||||||
|
[2025-01-28 12:45:05.986197] (Utility.Process) process [20183] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","for-each-ref","refs/namespaces/git-remote-annex/7d7560cd-2e80-489d-af4a-ec23b9b9abb7/","--format=%(objectname) %(refname)"]
|
||||||
|
[2025-01-28 12:45:05.992446] (Utility.Process) process [20183] done ExitSuccess
|
||||||
|
[2025-01-28 12:45:05.994823] (Utility.Process) process [20184] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/namespaces/git-remote-annex/7d7560cd-2e80-489d-af4a-ec23b9b9abb7/refs/heads/master","cee403c71ad8d180c149c26818b268b4fba67c3f"]
|
||||||
|
[2025-01-28 12:45:06.002395] (Utility.Process) process [20184] done ExitSuccess
|
||||||
|
[2025-01-28 12:45:06.006364] (Utility.Process) process [20185] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","bundle","create","--quiet","/var/folders/2p/4z266zp97g9f0w5xxx4hkjz40000gn/T/GITBUNDLE20173-0","--stdin"]
|
||||||
|
[2025-01-28 12:45:06.027734] (Utility.Process) process [20185] done ExitSuccess
|
||||||
|
[2025-01-28 12:45:06.028831] (Annex.Perms) freezing content .git/annex/objects/30/fM/GITBUNDLE-s595--7d7560cd-2e80-489d-af4a-ec23b9b9abb7-9aca839242a1231b8ea7d6c4544a582da92ec8a345a87d1f9ec2e7ac9c57917d/GITBUNDLE-s595--7d7560cd-2e80-489d-af4a-ec23b9b9abb7-9aca839242a1231b8ea7d6c4544a582da92ec8a345a87d1f9ec2e7ac9c57917d
|
||||||
|
[2025-01-28 12:45:06.032936] (Annex.Perms) freezing content directory .git/annex/objects/30/fM/GITBUNDLE-s595--7d7560cd-2e80-489d-af4a-ec23b9b9abb7-9aca839242a1231b8ea7d6c4544a582da92ec8a345a87d1f9ec2e7ac9c57917d
|
||||||
|
[2025-01-28 12:45:06.035315] (Utility.Process) process [20187] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
|
||||||
|
[2025-01-28 12:45:06.041878] (Utility.Process) process [20187] done ExitSuccess
|
||||||
|
[2025-01-28 12:45:06.044996] (Utility.Process) process [20188] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
|
||||||
|
[2025-01-28 12:45:06.051196] (Utility.Process) process [20188] done ExitSuccess
|
||||||
|
[2025-01-28 12:45:06.053205] (Utility.Process) process [20180] done ExitSuccess
|
||||||
|
[2025-01-28 12:45:06.057349] (Utility.Process) process [20191] call: cp ["-a","/var/folders/2p/4z266zp97g9f0w5xxx4hkjz40000gn/T/GITMANIFEST20173-3",".git/annex/objects/9q/z3/GITMANIFEST--7d7560cd-2e80-489d-af4a-ec23b9b9abb7.bak/GITMANIFEST--7d7560cd-2e80-489d-af4a-ec23b9b9abb7.bak"]
|
||||||
|
[2025-01-28 12:45:06.057467] (Utility.Process) process [20191] done ExitFailure (-9)
|
||||||
|
[2025-01-28 12:45:06.05756] (Annex.Perms) freezing content directory .git/annex/objects/9q/z3/GITMANIFEST--7d7560cd-2e80-489d-af4a-ec23b9b9abb7.bak
|
||||||
|
Push failed (Failed to upload manifest.)
|
||||||
|
[2025-01-28 12:45:06.06058] (Utility.Process) process [20192] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","for-each-ref","refs/namespaces/git-remote-annex/7d7560cd-2e80-489d-af4a-ec23b9b9abb7/","--format=%(objectname) %(refname)"]
|
||||||
|
[2025-01-28 12:45:06.068669] (Utility.Process) process [20192] done ExitSuccess
|
||||||
|
[2025-01-28 12:45:06.071203] (Utility.Process) process [20193] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","-d","refs/namespaces/git-remote-annex/7d7560cd-2e80-489d-af4a-ec23b9b9abb7/refs/heads/master","cee403c71ad8d180c149c26818b268b4fba67c3f"]
|
||||||
|
[2025-01-28 12:45:06.078439] (Utility.Process) process [20193] done ExitSuccess
|
||||||
|
warning: helper reported unexpected status of push
|
||||||
|
Everything up-to-date
|
||||||
|
[2025-01-28 12:45:06.081082] (Utility.Process) process [20194] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
|
||||||
|
[2025-01-28 12:45:06.0879] (Utility.Process) process [20194] done ExitSuccess
|
||||||
|
[2025-01-28 12:45:06.090302] (Utility.Process) process [20195] read: git ["--version"]
|
||||||
|
[2025-01-28 12:45:06.095789] (Utility.Process) process [20195] done ExitSuccess
|
||||||
|
[2025-01-28 12:45:06.096182] (Annex.Perms) freezing content .git/annex/misctmp/gaprobe
|
||||||
|
[2025-01-28 12:45:06.096262] (Annex.Perms) thawing content .git/annex/misctmp/gaprobe
|
||||||
|
[2025-01-28 12:45:06.09862] (Utility.Process) process [20196] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
|
||||||
|
% exit
|
||||||
|
% git config unset annex.debug
|
||||||
|
% git push --set-upstream local1 master
|
||||||
|
Full remote url: annex::7d7560cd-2e80-489d-af4a-ec23b9b9abb7?encryption=none&type=directory
|
||||||
|
Push failed (Failed to upload manifest.)
|
||||||
|
warning: helper reported unexpected status of push
|
||||||
|
Everything up-to-date
|
||||||
|
% git annex sync
|
||||||
|
commit
|
||||||
|
On branch master
|
||||||
|
nothing to commit, working tree clean
|
||||||
|
ok
|
||||||
|
pull local1
|
||||||
|
Full remote url: annex::7d7560cd-2e80-489d-af4a-ec23b9b9abb7?encryption=none&type=directory
|
||||||
|
git-annex: No git repository found in this remote.
|
||||||
|
ok
|
||||||
|
push local1
|
||||||
|
Full remote url: annex::7d7560cd-2e80-489d-af4a-ec23b9b9abb7?encryption=none&type=directory
|
||||||
|
Push failed (Failed to upload manifest.)
|
||||||
|
warning: helper reported unexpected status of push
|
||||||
|
warning: helper reported unexpected status of push
|
||||||
|
Everything up-to-date
|
||||||
|
ok
|
||||||
|
% git config set annex.debug true
|
||||||
|
% git annex sync
|
||||||
|
[2025-01-28 12:46:47.892399] (Utility.Process) process [22027] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
|
||||||
|
[2025-01-28 12:46:47.898879] (Utility.Process) process [22027] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:47.901826] (Utility.Process) process [22028] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
|
||||||
|
[2025-01-28 12:46:47.908197] (Utility.Process) process [22028] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:47.911039] (Utility.Process) process [22029] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
|
||||||
|
commit
|
||||||
|
[2025-01-28 12:46:47.92136] (Utility.Process) process [22030] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit","-a","-m","git-annex in andrew:/private/tmp/git-annex-testing/repo"]
|
||||||
|
[2025-01-28 12:46:47.981547] (Utility.Process) process [22035] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
|
||||||
|
[2025-01-28 12:46:47.988126] (Utility.Process) process [22035] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:47.990408] (Utility.Process) process [22036] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
|
||||||
|
[2025-01-28 12:46:47.996719] (Utility.Process) process [22036] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.000582] (Utility.Process) process [22037] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--cached","--name-only","-z","--diff-filter=ACMRT","--","."]
|
||||||
|
[2025-01-28 12:46:48.007367] (Utility.Process) process [22037] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.010028] (Utility.Process) process [22038] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
|
||||||
|
[2025-01-28 12:46:48.016108] (Utility.Process) process [22038] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.018541] (Utility.Process) process [22039] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
|
||||||
|
[2025-01-28 12:46:48.025954] (Utility.Process) process [22039] done ExitSuccess
|
||||||
|
On branch master
|
||||||
|
nothing to commit, working tree clean
|
||||||
|
[2025-01-28 12:46:48.043086] (Utility.Process) process [22030] done ExitFailure 1
|
||||||
|
ok
|
||||||
|
[2025-01-28 12:46:48.045582] (Utility.Process) process [22040] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
|
||||||
|
[2025-01-28 12:46:48.05211] (Utility.Process) process [22040] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.054886] (Utility.Process) process [22041] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
|
||||||
|
[2025-01-28 12:46:48.062284] (Utility.Process) process [22041] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.064679] (Utility.Process) process [22042] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/heads/synced/master"]
|
||||||
|
[2025-01-28 12:46:48.071504] (Utility.Process) process [22042] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.073977] (Utility.Process) process [22043] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/master..refs/heads/synced/master","--pretty=%H","-n1"]
|
||||||
|
[2025-01-28 12:46:48.080766] (Utility.Process) process [22043] done ExitSuccess
|
||||||
|
pull local1
|
||||||
|
[2025-01-28 12:46:48.084197] (Utility.Process) process [22044] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","fetch","local1"]
|
||||||
|
[2025-01-28 12:46:48.170637] (Utility.Process) process [22080] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
|
||||||
|
[2025-01-28 12:46:48.179566] (Utility.Process) process [22080] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.183611] (Utility.Process) process [22081] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
|
||||||
|
[2025-01-28 12:46:48.192055] (Utility.Process) process [22081] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.197482] (Utility.Process) process [22086] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
|
||||||
|
Full remote url: annex::7d7560cd-2e80-489d-af4a-ec23b9b9abb7?encryption=none&type=directory
|
||||||
|
[2025-01-28 12:46:48.215929] (Utility.Process) process [22087] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
|
||||||
|
[2025-01-28 12:46:48.223041] (Utility.Process) process [22087] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.225642] (Utility.Process) process [22088] read: git ["--version"]
|
||||||
|
[2025-01-28 12:46:48.231226] (Utility.Process) process [22088] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.231795] (Annex.Perms) freezing content .git/annex/misctmp/gaprobe
|
||||||
|
[2025-01-28 12:46:48.231889] (Annex.Perms) thawing content .git/annex/misctmp/gaprobe
|
||||||
|
git-annex: No git repository found in this remote.
|
||||||
|
[2025-01-28 12:46:48.239358] (Utility.Process) process [22044] done ExitFailure 128
|
||||||
|
ok
|
||||||
|
[2025-01-28 12:46:48.243384] (Utility.Process) process [22089] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
|
||||||
|
[2025-01-28 12:46:48.250955] (Utility.Process) process [22089] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.253625] (Utility.Process) process [22090] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
|
||||||
|
[2025-01-28 12:46:48.260937] (Utility.Process) process [22090] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.264403] (Utility.Process) process [22091] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
|
||||||
|
[2025-01-28 12:46:48.270737] (Utility.Process) process [22091] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.273298] (Utility.Process) process [22092] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
|
||||||
|
[2025-01-28 12:46:48.279777] (Utility.Process) process [22092] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.282444] (Utility.Process) process [22093] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","branch","-f","synced/master","refs/heads/master"]
|
||||||
|
[2025-01-28 12:46:48.290967] (Utility.Process) process [22093] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.293498] (Utility.Process) process [22094] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","refs/remotes/local1/synced/master"]
|
||||||
|
[2025-01-28 12:46:48.300336] (Utility.Process) process [22094] done ExitFailure 1
|
||||||
|
push local1
|
||||||
|
[2025-01-28 12:46:48.302852] (Utility.Process) process [22095] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","local1","master:synced/master","+git-annex:synced/git-annex"]
|
||||||
|
[2025-01-28 12:46:48.383262] (Utility.Process) process [22102] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
|
||||||
|
[2025-01-28 12:46:48.389482] (Utility.Process) process [22102] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.391771] (Utility.Process) process [22103] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
|
||||||
|
[2025-01-28 12:46:48.398109] (Utility.Process) process [22103] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.402067] (Utility.Process) process [22104] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
|
||||||
|
Full remote url: annex::7d7560cd-2e80-489d-af4a-ec23b9b9abb7?encryption=none&type=directory
|
||||||
|
[2025-01-28 12:46:48.41247] (Utility.Process) process [22105] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","for-each-ref","refs/namespaces/git-remote-annex/7d7560cd-2e80-489d-af4a-ec23b9b9abb7/","--format=%(objectname) %(refname)"]
|
||||||
|
[2025-01-28 12:46:48.419106] (Utility.Process) process [22105] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.42299] (Utility.Process) process [22106] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
|
||||||
|
[2025-01-28 12:46:48.430151] (Utility.Process) process [22106] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.434139] (Utility.Process) process [22107] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
|
||||||
|
[2025-01-28 12:46:48.440655] (Utility.Process) process [22107] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.44324] (Utility.Process) process [22108] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","for-each-ref","refs/namespaces/git-remote-annex/7d7560cd-2e80-489d-af4a-ec23b9b9abb7/","--format=%(objectname) %(refname)"]
|
||||||
|
[2025-01-28 12:46:48.449279] (Utility.Process) process [22108] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.452854] (Utility.Process) process [22109] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/namespaces/git-remote-annex/7d7560cd-2e80-489d-af4a-ec23b9b9abb7/refs/heads/synced/git-annex","b6817903fc3363e53ff863fcf79e90ab200130c3"]
|
||||||
|
[2025-01-28 12:46:48.460699] (Utility.Process) process [22109] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.463036] (Utility.Process) process [22110] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/namespaces/git-remote-annex/7d7560cd-2e80-489d-af4a-ec23b9b9abb7/refs/heads/synced/master","cee403c71ad8d180c149c26818b268b4fba67c3f"]
|
||||||
|
[2025-01-28 12:46:48.470252] (Utility.Process) process [22110] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.473412] (Utility.Process) process [22111] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","bundle","create","--quiet","/var/folders/2p/4z266zp97g9f0w5xxx4hkjz40000gn/T/GITBUNDLE22097-0","--stdin"]
|
||||||
|
[2025-01-28 12:46:48.494608] (Utility.Process) process [22111] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.49778] (Utility.Process) process [22104] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.505294] (Utility.Process) process [22116] call: cp ["-a","/var/folders/2p/4z266zp97g9f0w5xxx4hkjz40000gn/T/GITMANIFEST22097-3",".git/annex/objects/9q/z3/GITMANIFEST--7d7560cd-2e80-489d-af4a-ec23b9b9abb7.bak/GITMANIFEST--7d7560cd-2e80-489d-af4a-ec23b9b9abb7.bak"]
|
||||||
|
[2025-01-28 12:46:48.505403] (Utility.Process) process [22116] done ExitFailure (-9)
|
||||||
|
[2025-01-28 12:46:48.505502] (Annex.Perms) freezing content directory .git/annex/objects/9q/z3/GITMANIFEST--7d7560cd-2e80-489d-af4a-ec23b9b9abb7.bak
|
||||||
|
Push failed (Failed to upload manifest.)
|
||||||
|
[2025-01-28 12:46:48.507999] (Utility.Process) process [22117] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","for-each-ref","refs/namespaces/git-remote-annex/7d7560cd-2e80-489d-af4a-ec23b9b9abb7/","--format=%(objectname) %(refname)"]
|
||||||
|
[2025-01-28 12:46:48.514991] (Utility.Process) process [22117] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.518649] (Utility.Process) process [22118] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","-d","refs/namespaces/git-remote-annex/7d7560cd-2e80-489d-af4a-ec23b9b9abb7/refs/heads/synced/git-annex","b6817903fc3363e53ff863fcf79e90ab200130c3"]
|
||||||
|
[2025-01-28 12:46:48.525217] (Utility.Process) process [22118] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.528742] (Utility.Process) process [22119] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","-d","refs/namespaces/git-remote-annex/7d7560cd-2e80-489d-af4a-ec23b9b9abb7/refs/heads/synced/master","cee403c71ad8d180c149c26818b268b4fba67c3f"]
|
||||||
|
[2025-01-28 12:46:48.535612] (Utility.Process) process [22119] done ExitSuccess
|
||||||
|
warning: helper reported unexpected status of push
|
||||||
|
warning: helper reported unexpected status of push
|
||||||
|
Everything up-to-date
|
||||||
|
[2025-01-28 12:46:48.5386] (Utility.Process) process [22120] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
|
||||||
|
[2025-01-28 12:46:48.545982] (Utility.Process) process [22120] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.549657] (Utility.Process) process [22121] read: git ["--version"]
|
||||||
|
[2025-01-28 12:46:48.555248] (Utility.Process) process [22121] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.555667] (Annex.Perms) freezing content .git/annex/misctmp/gaprobe
|
||||||
|
[2025-01-28 12:46:48.555747] (Annex.Perms) thawing content .git/annex/misctmp/gaprobe
|
||||||
|
[2025-01-28 12:46:48.558896] (Utility.Process) process [22122] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
|
||||||
|
[2025-01-28 12:46:48.574158] (Utility.Process) process [22095] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.576864] (Utility.Process) process [22123] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","local1","git-annex"]
|
||||||
|
[2025-01-28 12:46:48.808953] (Utility.Process) process [22123] done ExitSuccess
|
||||||
|
[2025-01-28 12:46:48.813005] (Utility.Process) process [22148] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","push","local1","master"]
|
||||||
|
[2025-01-28 12:46:49.062622] (Utility.Process) process [22148] done ExitSuccess
|
||||||
|
ok
|
||||||
|
[2025-01-28 12:46:49.063559] (Utility.Process) process [22029] done ExitSuccess
|
||||||
|
%
|
||||||
|
|
||||||
|
|
||||||
|
% cat .git/config
|
||||||
|
[core]
|
||||||
|
repositoryformatversion = 0
|
||||||
|
filemode = true
|
||||||
|
bare = false
|
||||||
|
logallrefupdates = true
|
||||||
|
ignorecase = true
|
||||||
|
precomposeunicode = true
|
||||||
|
[annex]
|
||||||
|
uuid = bb331ff4-2e85-4657-869a-202d269d4b3c
|
||||||
|
version = 10
|
||||||
|
[filter "annex"]
|
||||||
|
smudge = git-annex smudge -- %f
|
||||||
|
clean = git-annex smudge --clean -- %f
|
||||||
|
process = git-annex filter-process
|
||||||
|
[remote "local1"]
|
||||||
|
annex-directory = /tmp/git-annex-testing/specialdirectoryremote
|
||||||
|
annex-uuid = 7d7560cd-2e80-489d-af4a-ec23b9b9abb7
|
||||||
|
skipFetchAll = true
|
||||||
|
url = annex::
|
||||||
|
fetch = +refs/heads/*:refs/remotes/foo/*
|
||||||
|
%
|
||||||
|
"""]]
|
||||||
|
|
||||||
|
### 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)
|
||||||
|
Yup!
|
||||||
|
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="matrss"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/cd1c0b3be1af288012e49197918395f0"
|
||||||
|
subject="comment 3"
|
||||||
|
date="2025-01-27T15:08:57Z"
|
||||||
|
content="""
|
||||||
|
I can still reproduce this issue with 10.20250115, but in my testing it seems like it only happens against a forgejo-aneksajo instance on localhost without TLS, not against a different remote instance. This setup required `git config annex.security.allowed-ip-addresses 127.0.0.1`, maybe it has something to do with that or TLS...
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="matrss"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/cd1c0b3be1af288012e49197918395f0"
|
||||||
|
subject="comment 4"
|
||||||
|
date="2025-01-27T15:14:44Z"
|
||||||
|
content="""
|
||||||
|
It definitely takes a different code path somehow, as I don't see the `Utility.Url` debug messages when the remote is not on localhost.
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,69 @@
|
||||||
|
### Please describe the problem.
|
||||||
|
|
||||||
|
When setting up an (SSH) rsync remote, and _not_ adding the `:` at the end of the hostname, it will create a local folder instead of copying to remote.
|
||||||
|
|
||||||
|
```
|
||||||
|
[joe@laptop]$ git annex initremote myremote type=rsync rsyncurl=ssh.example.com encryption=hybrid keyid=00001111222233334444
|
||||||
|
[joe@laptop]$ git annex copy . --to myremote
|
||||||
|
copy metal-arm64.raw (to rpi50...)
|
||||||
|
ok
|
||||||
|
copy nixos-gnome-24.11.712512.3f0a8ac25fb6-x86_64-linux.iso (to myremote...)
|
||||||
|
ok
|
||||||
|
(recording state in git...)
|
||||||
|
[joe@laptop]$ ls -l
|
||||||
|
insgesamt 246792
|
||||||
|
lrwxrwxrwx. 1 joe joe 204 20. Jan 21:01 metal-arm64.raw -> .git/annex/objects/mG/21/SHA256E-s1306525696--21308f635774faf611ba35c9b04d638aeb7afb1b1c1db949ae65ff81cdafe8b7.raw/SHA256E-s1306525696--21308f635774faf611ba35c9b04d638aeb7afb1b1c1db949ae65ff81cdafe8b7.raw
|
||||||
|
lrwxrwxrwx. 1 joe joe 204 20. Jan 21:01 nixos-gnome-24.11.712512.3f0a8ac25fb6-x86_64-linux.iso -> .git/annex/objects/fX/g9/SHA256E-s2550136832--da2fe173a279d273bf5a999eafdb618db0642f4a3df95fd94a6585c45082a7f0.iso/SHA256E-s2550136832--da2fe173a279d273bf5a999eafdb618db0642f4a3df95fd94a6585c45082a7f0.iso
|
||||||
|
drwxr-xr-x. 1 joe joe 12 26. Jan 11:32 ssh.example.com # <---- for me, that was not expected behaviour
|
||||||
|
```
|
||||||
|
|
||||||
|
It might be a feature I don't understand, but because I couldn't find documentation about it, I am leaning towards non-intended behaviour. My assumption would be, that a rsync operation to a local directory is already implemented with the [directory special remote](https://git-annex.branchable.com/special_remotes/directory/).
|
||||||
|
|
||||||
|
### What steps will reproduce the problem?
|
||||||
|
|
||||||
|
Have a remote rsync server, where you don't need to specify the base directory. In my case [this is done with NixOS and this configuration which uses `rrsync`](https://wiki.nixos.org/wiki/Rsync).
|
||||||
|
|
||||||
|
The following configures the rsync remote, and later pushed files to it (so far expected behaviour):
|
||||||
|
|
||||||
|
```
|
||||||
|
git annex initremote myremote type=rsync rsyncurl=ssh.example.com: encryption=hybrid keyid=00001111222233334444
|
||||||
|
git annex copy . --to myremote
|
||||||
|
```
|
||||||
|
|
||||||
|
This however, doesn't copy to the correct remote, but creates a local folder named `ssh.example.com` in my annexed directory instead (note the missing `:` after the hostname):
|
||||||
|
|
||||||
|
```
|
||||||
|
git annex initremote myremote type=rsync rsyncurl=ssh.example.com encryption=hybrid keyid=00001111222233334444
|
||||||
|
git annex copy . --to myremote # will copy successfully, BUT
|
||||||
|
ls -l # shows the folder `ssh.example.com` in my directory with the files in it, the rsync remote is empty
|
||||||
|
```
|
||||||
|
|
||||||
|
### What version of git-annex are you using? On what operating system?
|
||||||
|
|
||||||
|
* Fedora 41
|
||||||
|
|
||||||
|
```
|
||||||
|
git-annex version: 10.20240701
|
||||||
|
build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark 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)
|
||||||
|
|
||||||
|
I am just now starting to _really_ use git-annex, after following it's development and every blogpost you wrote about it for almost a decade now. Thank you for a tool desperately needed!
|
||||||
|
|
@ -0,0 +1,12 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="matrss"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/cd1c0b3be1af288012e49197918395f0"
|
||||||
|
subject="comment 1"
|
||||||
|
date="2025-01-27T11:28:43Z"
|
||||||
|
content="""
|
||||||
|
I'd say this is intended behavior: I assume that the rsyncurl option is more less passed verbatim to rsync, and rsync can act on both local and remote paths. There is the possibility to use `rsync://` URLs, remote paths via SSH where the host and path are separated by a colon, and local paths.
|
||||||
|
|
||||||
|
The rsync special remote with local paths behaves a bit differently than the directory special remote, namely the rsyncurl is remembered (e.g. for autoenable) while the directory special remote does not remember the directory. There can be use-cases for both.
|
||||||
|
|
||||||
|
Besides, most of the time I think one would want to specify a remote directory with rsync, in which case the colon is necessary anyway.
|
||||||
|
"""]]
|
||||||
|
|
@ -6,7 +6,7 @@ locally paired systems, and remote servers with rsync.
|
||||||
Help me prioritize my work: What special remote would you most like
|
Help me prioritize my work: What special remote would you most like
|
||||||
to use with the git-annex assistant?
|
to use with the git-annex assistant?
|
||||||
|
|
||||||
[[!poll open=yes 18 "Amazon S3 (done)" 13 "Amazon Glacier (done)" 10 "Box.com (done)" 79 "My phone (or MP3 player)" 29 "Tahoe-LAFS" 19 "OpenStack SWIFT" 37 "Google Drive"]]
|
[[!poll open=yes 18 "Amazon S3 (done)" 13 "Amazon Glacier (done)" 10 "Box.com (done)" 81 "My phone (or MP3 player)" 29 "Tahoe-LAFS" 19 "OpenStack SWIFT" 37 "Google Drive"]]
|
||||||
|
|
||||||
This poll is ordered with the options I consider easiest to build
|
This poll is ordered with the options I consider easiest to build
|
||||||
listed first. Mostly because git-annex already supports them and they
|
listed first. Mostly because git-annex already supports them and they
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1 @@
|
||||||
|
I run a server and have a 2.5TB repo on a 4TB drive. Right now I have a bare repo for outside connections on it, but thought about a non-bare repo beside this on the same drive for local use. Does git-annex realize the repos are on the same btrfs-volume and uses ```cp --reflink``` while syncing between them?
|
||||||
|
|
@ -0,0 +1,10 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="Atemu"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/6ac9c136a74bb8760c66f422d3d6dc32"
|
||||||
|
subject="comment 1"
|
||||||
|
date="2025-01-26T02:36:51Z"
|
||||||
|
content="""
|
||||||
|
It will not realise this.
|
||||||
|
|
||||||
|
Why do you have separate repos for this though? You can absolutely just use a non-plain git repo for synchronisation purposes too.
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="jnkl"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/2ab576f3bf2e0d96b1ee935bb7f33dbe"
|
||||||
|
subject="comment 2"
|
||||||
|
date="2025-01-26T13:09:04Z"
|
||||||
|
content="""
|
||||||
|
Sorry, I am new to git. I thought pushes are only allowed to bare repositories. Am I wrong?
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="Atemu"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/6ac9c136a74bb8760c66f422d3d6dc32"
|
||||||
|
subject="comment 3"
|
||||||
|
date="2025-01-26T13:30:10Z"
|
||||||
|
content="""
|
||||||
|
git-annex synchronises branch state via the `synced/branchnamehere` branches. The actual checked out branch in the worktree will only be updated when you run a `merge` or `sync` in the worktree.
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="jnkl"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/2ab576f3bf2e0d96b1ee935bb7f33dbe"
|
||||||
|
subject="comment 4"
|
||||||
|
date="2025-01-28T21:20:17Z"
|
||||||
|
content="""
|
||||||
|
Thank you. So bare repositories are only needed when I want to save disk space with git annex?
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="Atemu"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/6ac9c136a74bb8760c66f422d3d6dc32"
|
||||||
|
subject="comment 5"
|
||||||
|
date="2025-01-28T21:57:42Z"
|
||||||
|
content="""
|
||||||
|
Indeed. However the space savings would likely be marginal in a typical git-annex repo.
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,26 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="Atemu"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/6ac9c136a74bb8760c66f422d3d6dc32"
|
||||||
|
subject="comment 2"
|
||||||
|
date="2025-01-26T02:54:18Z"
|
||||||
|
content="""
|
||||||
|
My issue apparently had to do with numcopies? I first passed `--numcopies 2` because I was curious but it didn't change anything. Then I passed `--numcopies 1` and it immediately dropped all the files as I'd have expected it to at `numcopies=3`. Running another sync without `--numcopies` didn't attempt to pull in the dropped files either.
|
||||||
|
|
||||||
|
This smells like a bug? If numcopies was actually violated, it should attempt to correct that again, right? (All files were available from a connected repo.)
|
||||||
|
|
||||||
|
Here are the numcopies stats from `git annex info .`:
|
||||||
|
|
||||||
|
```
|
||||||
|
numcopies stats:
|
||||||
|
numcopies +1: 1213
|
||||||
|
numcopies +0: 25310
|
||||||
|
```
|
||||||
|
|
||||||
|
Some more background: I have a bunch of drives that are offline that I have set to be trusted. One repo on my NAS is online at all times and semitrusted.
|
||||||
|
|
||||||
|
I have two offline groups: `cold` and `lukewarm`. All drives in those groups are trusted.
|
||||||
|
|
||||||
|
It's weird that it didn't work with 2 but did work with 1. This leads me to believe it could have been due to the one repo being online while the others are offline and trusted; acting more like mincopies. Was behaviour changed in this regard recently?
|
||||||
|
|
||||||
|
I'd still like to know how to debug wanted expressions too though.
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,31 @@
|
||||||
|
Is there a way to obtain/keep the overview over a git annex repository with many directories and files? For example to answer the following question in a compact way: which subdirectories of the current directory are complete locally?
|
||||||
|
|
||||||
|
The needed information is provided by both `git annex list` and `git annex info`, but the output of both command is very verbose and difficult to parse visually.
|
||||||
|
|
||||||
|
For example part of the output of `git annex list` could be:
|
||||||
|
|
||||||
|
```
|
||||||
|
XXX__ foo/bar/a
|
||||||
|
XXX__ foo/bar/b
|
||||||
|
XXX__ foo/bar/c
|
||||||
|
XXX__ foo/hey/d
|
||||||
|
XXX__ foo/hey/e
|
||||||
|
XXX__ foo/hey/f
|
||||||
|
```
|
||||||
|
|
||||||
|
Assuming that the `foo` directory contains no further files this could be compacted to
|
||||||
|
|
||||||
|
```
|
||||||
|
XXX__ foo/bar/
|
||||||
|
XXX__ foo/hey/
|
||||||
|
```
|
||||||
|
|
||||||
|
or even
|
||||||
|
|
||||||
|
```
|
||||||
|
XXX__ foo/
|
||||||
|
```
|
||||||
|
|
||||||
|
Of course the above procedure would only compact directories if all files have the same presence status. But I guess that this will be true in many cases.
|
||||||
|
|
||||||
|
I’m thinking about implementing this as a filter to the output of `git annex list`, but wanted to check whether similar ideas haven’t been considered here before. (I could not find anything.)
|
||||||
15
doc/forum/Reasonable_annex.bloomcapacity__63__.mdwn
Normal file
15
doc/forum/Reasonable_annex.bloomcapacity__63__.mdwn
Normal file
|
|
@ -0,0 +1,15 @@
|
||||||
|
What is a reasonable value for ```annex.bloomcapacity``` in this situation and in what unit?
|
||||||
|
|
||||||
|
local annex keys: 670671
|
||||||
|
local annex size: 2.62 terabytes
|
||||||
|
annexed files in working tree: 1410199
|
||||||
|
size of annexed files in working tree: 3.52 terabytes
|
||||||
|
combined annex size of all repositories: 2.63 terabytes
|
||||||
|
annex sizes of repositories:
|
||||||
|
2.62 TB: b2e77041-584e-4699-947d-ef5004273901 -- pudong [here]
|
||||||
|
7.39 GB: 42a53a13-7ad6-43a5-95ef-813d4f8c1a6f -- [batam_payload]
|
||||||
|
backend usage:
|
||||||
|
SHA256E: 1410199
|
||||||
|
bloom filter size: 32 mebibytes (appears too small for this repository; adjust annex.bloomcapacity)
|
||||||
|
|
||||||
|
I don't really understand what happens when the bloom filter is too small.
|
||||||
|
|
@ -0,0 +1,18 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 1"""
|
||||||
|
date="2025-01-29T15:54:19Z"
|
||||||
|
content="""
|
||||||
|
What will happen with too small a bloom filter is `git-annex unused` may
|
||||||
|
think that some keys are used which are really not. And
|
||||||
|
`git-annex sync --content` may operate on some keys that are not in the
|
||||||
|
work tree.
|
||||||
|
|
||||||
|
The `git-annex info` command displays how much memory the configured bloom
|
||||||
|
filters use, which is why it's reporting 32 membibytes. But the
|
||||||
|
annex.bloomcapacity setting is the number of expected files in the work
|
||||||
|
tree, by default 500000.
|
||||||
|
|
||||||
|
It would probably make sense for you to set it to 2000000 or so unless
|
||||||
|
your system has an unusually small amount of RAM.
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,18 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="dmcardle"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/b79468a0d03ec3ec7acbae547c4fa994"
|
||||||
|
subject="comment 1"
|
||||||
|
date="2025-01-29T14:44:37Z"
|
||||||
|
content="""
|
||||||
|
Hi, author of rclone's \"gitannex\" command here. Sorry you're running into trouble with it!
|
||||||
|
|
||||||
|
Based on the text, that error is definitely coming from [gitannex.go](https://github.com/rclone/rclone/blob/6494ac037fdd7ada2052ae9a8e05d230e7e686b2/cmd/gitannex/gitannex.go#L276).
|
||||||
|
|
||||||
|
I believe that my intent was to detect that the following mkdir would fail, and offer up a more specific error message rather than letting it fail.
|
||||||
|
|
||||||
|
I don't know anything about Backblaze B2, unfortunately. I suppose we could work around the issue by creating an empty file underneath the place we want the empty directory. Sounds plausible, right?
|
||||||
|
|
||||||
|
Would you mind trying to make an empty directory on your B2 remote to verify it fails? Something like `rclone mkdir myremote:newdir`.
|
||||||
|
|
||||||
|
And also try touching a file in a new directory to verify it's possible in one go? Something like `rclone touch --recursive myremote:newdir/newfile.txt`.
|
||||||
|
"""]]
|
||||||
5
doc/forum/reuploads_existing_files_to_bare_repo.mdwn
Normal file
5
doc/forum/reuploads_existing_files_to_bare_repo.mdwn
Normal file
|
|
@ -0,0 +1,5 @@
|
||||||
|
I created a bare repo on a small always on server and synced it with my desktop.
|
||||||
|
|
||||||
|
Now, when I sync it with my laptop, annex on the laptop reuploads all files, which were already uploaded by the desktop. I see that because annex on the laptop fills the upstream even though the bare repo on the server does not take more harddisk space while this happens.
|
||||||
|
|
||||||
|
Is this by design and why?
|
||||||
|
|
@ -0,0 +1,24 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 1"""
|
||||||
|
date="2025-01-22T20:43:32Z"
|
||||||
|
content="""
|
||||||
|
If the laptop has not pulled from the server since those files were sent to
|
||||||
|
it, it does not know the server contains the files yet. So it will try to
|
||||||
|
send them again. Normally this won't result in the same content being
|
||||||
|
actually sent again, instead for each file it will check if the file is in
|
||||||
|
the server yet, and when it sees it is, it won't send it again.
|
||||||
|
|
||||||
|
My first guess is that just the network overhead of doing those checks is
|
||||||
|
what "fills the upstream".
|
||||||
|
|
||||||
|
It is possible that it's actually re-uploading files that the server
|
||||||
|
already has, without checking it first, which will result in the server
|
||||||
|
accepting the upload and then throwing it away, since it already has the content.
|
||||||
|
This can happen eg, if the same file is being sent into a repository from
|
||||||
|
two other repositories at the same time. But I don't know of any common
|
||||||
|
situations where it happens.
|
||||||
|
|
||||||
|
So, if you're sure it's doing that, please provide details about what exact
|
||||||
|
git-annex commands you're running that are causing it to do that.
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,8 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="jnkl"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/2ab576f3bf2e0d96b1ee935bb7f33dbe"
|
||||||
|
subject="comment 2"
|
||||||
|
date="2025-01-25T11:49:29Z"
|
||||||
|
content="""
|
||||||
|
I don't think it was the overhead (stopped it at uploaded 30G for a 180G repo). I am in the process of recreating the repo, so I can't give you further information for now. Will come back to you if it happens again. Thanks for your answer and your awesome work!
|
||||||
|
"""]]
|
||||||
|
|
@ -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`?
|
||||||
|
"""]]
|
||||||
|
|
@ -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 ;)
|
||||||
|
"""]]
|
||||||
|
|
@ -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)
|
||||||
|
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,44 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
|
||||||
|
nickname="beryllium"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
|
||||||
|
subject="Simple config amendment for Apache served repositories"
|
||||||
|
date="2025-01-28T08:34:40Z"
|
||||||
|
content="""
|
||||||
|
If you follow the [git-http-backend][id] documentation for serving repositories via Apache, you'll read this section:
|
||||||
|
|
||||||
|
<code>
|
||||||
|
<p>To serve gitweb at the same url, use a ScriptAliasMatch to only
|
||||||
|
those URLs that <em>git http-backend</em> can handle, and forward the
|
||||||
|
rest to gitweb:</p>
|
||||||
|
</div>
|
||||||
|
<div class=\"listingblock\">
|
||||||
|
<div class=\"content\">
|
||||||
|
<pre>ScriptAliasMatch \
|
||||||
|
\"(?x)^/git/(.*/(HEAD | \
|
||||||
|
info/refs | \
|
||||||
|
objects/(info/[^/]+ | \
|
||||||
|
[0-9a-f]{2}/[0-9a-f]{38} | \
|
||||||
|
pack/pack-[0-9a-f]{40}\.(pack|idx)) | \
|
||||||
|
git-(upload|receive)-pack))$\" \
|
||||||
|
/usr/libexec/git-core/git-http-backend/$1
|
||||||
|
|
||||||
|
ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/</pre>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
</code>
|
||||||
|
|
||||||
|
If you add the following AliasMatch between the two ScriptAlias directives, you can get Apache to serve the (...).git/config file to the http client, in this case git-annex.
|
||||||
|
|
||||||
|
<pre>
|
||||||
|
AliasMatch \"(?x)^/git/(.*/config)$\" /var/www/git/$1
|
||||||
|
</pre>
|
||||||
|
|
||||||
|
This allows the annexes to use the autoenable=true to pin the centralisation afforded by the git only repository. Keep a \"source of truth\" so to speak (acknowledging that this is antithetical to what git-annex aims to do).
|
||||||
|
|
||||||
|
As an aside, the tip to generate a uuid didn't seem to work for me. But I suspect I missed the point somewhat.
|
||||||
|
|
||||||
|
Regardless, if you are able to alter the configuration of your \"centralised\" git repository, this might be of assistance.
|
||||||
|
|
||||||
|
[id]: https://git-scm.com/docs/git-http-backend \"git-http-backend\"
|
||||||
|
"""]]
|
||||||
|
|
@ -8,17 +8,24 @@ Some commands like `git-annex find` use RawFilePath end-to-end.
|
||||||
But this conversion is not yet complete. This is a todo to keep track of the
|
But this conversion is not yet complete. This is a todo to keep track of the
|
||||||
status.
|
status.
|
||||||
|
|
||||||
* The Abstract FilePath proposal (AFPP) has been implemented, and so a number of
|
* unix has modules that operate on RawFilePath but no OSPath versions yet.
|
||||||
libraries like unix and directory now have versions that operate on
|
See https://github.com/haskell/unix/issues/240
|
||||||
OSPath. That could be used in git-annex eg for things like
|
* filepath-1.4.100 implements support for OSPath. It is bundled with
|
||||||
getDirectoryContents, when built against those versions.
|
ghc-9.6.1 and above. Will need to switch from filepath-bytestring to
|
||||||
(But OSPath uses ShortByteString, while RawFilePath is ByteString, so
|
this, and to avoid a lot of ifdefs, probably only after git-annex no
|
||||||
conversion still entails a copy.)
|
longers supports building with older ghc versions. This will entail
|
||||||
* withFile remains to be converted, and is used in several important code
|
replacing all the RawFilePath with OsPath, which should be pretty
|
||||||
paths, including Annex.Journal and Annex.Link.
|
mechanical, with only some wrapper functions in Utility.FileIO and
|
||||||
There is a RawFilePath version in file-io library, but that is
|
Utility.RawFilePath needing to be changed.
|
||||||
not currently a git-annex dependency. (withFile is in base, and base is
|
* Utility.FileIO is used for most withFile and openFile, but not yet for
|
||||||
unlikely to convert to AFPP soon)
|
readFile, writeFile, and appendFile on FilePaths.
|
||||||
|
Note that the FilePath versions do newline translation on windows,
|
||||||
|
which has to be handled when converting to the Utility.FileIO ones.
|
||||||
|
* System.Directory.OsPath is available with OsPath build flag, but
|
||||||
|
not yet used, and would eliminate a lot of fromRawFilePaths.
|
||||||
|
Make Utility.SystemDirectory import it when built with OsPath,
|
||||||
|
and the remaining 6 hours or work will explain itself..
|
||||||
|
This has been started in the `ospath` branch.
|
||||||
|
|
||||||
[[!tag confirmed]]
|
[[!tag confirmed]]
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,70 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 10"""
|
||||||
|
date="2025-01-28T14:06:41Z"
|
||||||
|
content="""
|
||||||
|
Using metadata to store the inputs of computations like I did in my example
|
||||||
|
above seems that it would allow the metadata to be changed later, which
|
||||||
|
would change the output when a key gets recomputed. That feels surprising,
|
||||||
|
because metadata could be changed for any reason, without the intention
|
||||||
|
of affecting a compute special remote.
|
||||||
|
|
||||||
|
It might be possible for git-annex to pin down the current state of
|
||||||
|
metadata (or the whole git-annex branch) and provide the same input to the
|
||||||
|
computation when it's run again. (Unless `git-annex forget` has caused
|
||||||
|
that old branch state to be lost..) But it can't fully isolate the program
|
||||||
|
from all unpinned inputs without using some form of containerization,
|
||||||
|
which feels out of scope for git-annex.
|
||||||
|
|
||||||
|
Instead of using metadata, the input values could be stored in the
|
||||||
|
per-special-remote state of the generated key. Or the input values could be
|
||||||
|
encoded in the key itself, but then two computations that generate the same
|
||||||
|
output would have two different keys, rather than hashing to the same key.
|
||||||
|
|
||||||
|
Using a key with a regular hash backend also lets the user find out if the
|
||||||
|
computation turns out to not be reproducible later for whatever reason;
|
||||||
|
getting the file from the compute special remote will fail at hash
|
||||||
|
verification time. Something like a VURL key could still alternatively be
|
||||||
|
used in cases where reproducibility is not important.
|
||||||
|
|
||||||
|
To add a computed file, the interface would look close to the same,
|
||||||
|
but now the --value options are setting fields in the compute special
|
||||||
|
remote's state:
|
||||||
|
|
||||||
|
git-annex addcomputed foo --to ffmpeg-cut \
|
||||||
|
--input source=input.mov \
|
||||||
|
--value starttime=15:00 \
|
||||||
|
--value endtime=30:00
|
||||||
|
|
||||||
|
The values could be provided to the "git-annex-compute-" program with
|
||||||
|
environment variables.
|
||||||
|
|
||||||
|
For `--input source=foo`, it could look up the git-annex key (or git sha1)
|
||||||
|
of that file, and store that in the state. So it would provide the compute
|
||||||
|
program with the same data every time. But it could *also* store the
|
||||||
|
filename. And that allows for a command like this:
|
||||||
|
|
||||||
|
git-annex recompute foo --from ffmpeg-cut
|
||||||
|
|
||||||
|
Which, when the input.mov file has been changed, would re-run the
|
||||||
|
computation with the new content of the file, and stage a new version of
|
||||||
|
the computed file. It could even be used to recompute every file in a tree:
|
||||||
|
|
||||||
|
git-annex recompute . --from ffmpeg-cut
|
||||||
|
|
||||||
|
Also, that command could let input values be adjusted later:
|
||||||
|
|
||||||
|
git-annex recompute foo --from ffmpeg-cut --value starttime=14:50
|
||||||
|
git commit -m 'include the introduction of the speaker in the clip'
|
||||||
|
|
||||||
|
It would also be good to have a command that examines a computed key
|
||||||
|
and displays the values and inputs. That could be `git-annex whereis`
|
||||||
|
or perhaps a dedicated command with more structured output:
|
||||||
|
|
||||||
|
git-annex examinecompute foo --from ffmpeg-cut
|
||||||
|
source=input.mov (annex key SHA256--xxxxxxxxx)
|
||||||
|
starttime=15:00
|
||||||
|
endtime=30:00
|
||||||
|
|
||||||
|
This all feels like it might allow for some useful workflows...
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,24 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""Re: worktree provisioning"""
|
||||||
|
date="2025-01-28T14:08:29Z"
|
||||||
|
content="""
|
||||||
|
@m.risse in your example the "data.nc" file gets new content when
|
||||||
|
retrieved from the special remote and the source file has changed.
|
||||||
|
|
||||||
|
But if you already have data.nc file present in a repository, it
|
||||||
|
does not get updated immediately when you update the source
|
||||||
|
"data.grib" file.
|
||||||
|
|
||||||
|
So, a drop and re-get of a file changes the version of the file you have
|
||||||
|
available. For that matter, if the old version has been stored on other
|
||||||
|
remotes, a get may retrieve either an old or a new version.
|
||||||
|
That is not intuitive and it makes me wonder if using a
|
||||||
|
special remote is really a good fit for what you're wanting to do.
|
||||||
|
|
||||||
|
In your "cdo" example, it's not clear to me if the new version of the
|
||||||
|
software generates an identical file to the old, or if it has a bug fix
|
||||||
|
that causes it to generate a significantly different output. If the two
|
||||||
|
outputs are significantly different then treating them as the same
|
||||||
|
git-annex key seems questionable to me.
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,29 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 12"""
|
||||||
|
date="2025-01-28T15:39:44Z"
|
||||||
|
content="""
|
||||||
|
My design so far does not fully support
|
||||||
|
"Request one key, receive many".
|
||||||
|
|
||||||
|
My `git-annex addcomputed` command doesn't handle the case where a
|
||||||
|
computation generates multiple output files. While the `git-annex-compute-`
|
||||||
|
command's interface could let it return several computed files, addcomputed
|
||||||
|
would only adds one file to the name that the user specifies. What is it
|
||||||
|
supposed to do if the computation generates more than one? Maybe it needs a
|
||||||
|
way to let a whole directory be populated with the files generated by a
|
||||||
|
computation. Or a way to specify multiple files to add.
|
||||||
|
|
||||||
|
And here's another problem:
|
||||||
|
Suppose I have one very expensive computation that generates files foo
|
||||||
|
and bar. And a second, less expensive computation, that also generates foo
|
||||||
|
(same content) as well as generating baz. Both computations are run on the
|
||||||
|
same compute special remote. Now if the user runs `git-annex get foo`,
|
||||||
|
they will be unhappy if it chooses to run the expensive computation,
|
||||||
|
rather than the less expensive computation.
|
||||||
|
|
||||||
|
Since the per-special remote state for a key is used as the computation
|
||||||
|
input, only one input can be saved for foo's key. So it wouldn't really be
|
||||||
|
picking between two alernatives, it would just use whatever the current
|
||||||
|
state for that key is.
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,24 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="matrss"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/cd1c0b3be1af288012e49197918395f0"
|
||||||
|
subject="comment 13"
|
||||||
|
date="2025-01-29T09:56:12Z"
|
||||||
|
content="""
|
||||||
|
> @m.risse in your example the \"data.nc\" file gets new content when retrieved from the special remote and the source file has changed.
|
||||||
|
|
||||||
|
True, that can happen, and the user was explicit in that they either don't care about it (non-checksum backend, URL in my PoC), or do care (checksum backend) and git-annex would fail the checksum verification.
|
||||||
|
|
||||||
|
> But if you already have data.nc file present in a repository, it does not get updated immediately when you update the source \"data.grib\" file.
|
||||||
|
>
|
||||||
|
> So, a drop and re-get of a file changes the version of the file you have available. For that matter, if the old version has been stored on other remotes, a get may retrieve either an old or a new version. That is not intuitive and it makes me wonder if using a special remote is really a good fit for what you're wanting to do
|
||||||
|
|
||||||
|
This I haven't entirely thought through. I'd say if the key uses a non-checksum backend, then it can only be assumed and is the users responsibility that the resulting file is functionally, even if not bit-by-bit, identical. E.g. with netCDF checksums can differ due to small details like chunking, but the data might be the same. With a checksum backend git-annex would just fail the next recompute, but the interactions with copies on other remotes could indeed get confusing.
|
||||||
|
|
||||||
|
> In your \"cdo\" example, it's not clear to me if the new version of the software generates an identical file to the old, or if it has a bug fix that causes it to generate a significantly different output. If the two outputs are significantly different then treating them as the same git-annex key seems questionable to me.
|
||||||
|
|
||||||
|
Again, two possible cases depending on if the key uses a checksum or a non-checksum backend. With a checksum: if the new version produces the same output everything is fine; if the new version produces different output then git-annex would indicate this discrepancy on the next recompute and the user has to decide how to handle it (probably by checking that the output of the new version is either functionally the same or in some way \"better\" than the old one and updating the repository to record this new key as that file).
|
||||||
|
|
||||||
|
Without a checksum backend the user would again have been explicit in that they don't care if the data changes for whatever reason, the key is essentially just a placeholder for the computation without a guarantee about its content.
|
||||||
|
|
||||||
|
Something like VURL would be a compromise between the two: it would avoid the upfront cost of computing all files (which might be very expensive), but still instruct git-annex to error out if the checksum changes at some point after the first compute. A regular migration of the computed-files-so-far to a checksum backend could achieve the same.
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,11 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="matrss"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/cd1c0b3be1af288012e49197918395f0"
|
||||||
|
subject="comment 14"
|
||||||
|
date="2025-01-29T10:13:59Z"
|
||||||
|
content="""
|
||||||
|
Some thoughts regarding your ideas:
|
||||||
|
|
||||||
|
- Multiple output files could always be emulated by generating a single archive file and registering additional compute instructions that simply extract each output file from that archive. I think there could be some convenience functionality on the CLI side to set that up and the key of the archive file might not even need to correspond to an actual file in the tree.
|
||||||
|
- For my use-cases (and I think DataLad at large) it is important to make this feature work across repository boundaries. E.g. I would like to use this feature to build a derived dataset from <https://atris.fz-juelich.de/MeteoCloud/ERA5>, where exactly this conversion from grib to netcdf happens in the compute step. I'd like to have the netcdf outputs as a separate dataset as some users might only be interested in the grib files, and it would scale better when there is more than just one kind of output that can be derived from an input by computation. `git annex get` doesn't work recursively across submodules/subdatasets though, and `datalad get` does not understand keys, just paths (at least so far).
|
||||||
|
"""]]
|
||||||
|
|
@ -3,5 +3,5 @@
|
||||||
subject="""comment 3"""
|
subject="""comment 3"""
|
||||||
date="2024-04-30T19:31:35Z"
|
date="2024-04-30T19:31:35Z"
|
||||||
content="""
|
content="""
|
||||||
See also [[todo/wishlist__58___derived_content_support]].
|
See also [[todo/wishlist:_derived_content_support]].
|
||||||
"""]]
|
"""]]
|
||||||
|
|
|
||||||
|
|
@ -3,11 +3,30 @@
|
||||||
subject="""comment 6"""
|
subject="""comment 6"""
|
||||||
date="2024-04-30T19:53:43Z"
|
date="2024-04-30T19:53:43Z"
|
||||||
content="""
|
content="""
|
||||||
On trust, it seems to me that if someone chooses to enable a particular
|
On trust, it seems to me that if someone chooses to install a
|
||||||
special remote, they are choosing to trust whatever kind of computations it
|
particular special remote, they are choosing to trust whatever kind of
|
||||||
supports.
|
computations it supports.
|
||||||
|
|
||||||
Eg a special remote could choose to always run a computation inside a
|
Eg a special remote could choose to always run a computation inside a
|
||||||
particular container system and then if you trust that container system is
|
particular container system and then if you trust that container system is
|
||||||
secure, you can choose to use it.
|
secure, you can choose to install it.
|
||||||
|
|
||||||
|
Enabling the special remote is not necessary, because a
|
||||||
|
repository can be set to autoenable a special remote. In some sense this is
|
||||||
|
surprising. I had originally talked about enabling here and then I
|
||||||
|
remembered autoenable.
|
||||||
|
|
||||||
|
It may be that autoenable should only be allowed for
|
||||||
|
special remote programs that the user explicitly whitelists, not only
|
||||||
|
installs into PATH. That would break some existing workflows, though
|
||||||
|
setting some git configs would not be too hard.
|
||||||
|
|
||||||
|
There seems scope for both compute special remotes that execute code that
|
||||||
|
comes from the git repository, and ones that only have metadata about the
|
||||||
|
computation recorded in the git repository, in a way that cannot let them
|
||||||
|
execute arbitrary code under the control of the git repository.
|
||||||
|
|
||||||
|
A well-behaved compute special remote that does run code that comes from a
|
||||||
|
git repository could require an additional git config to be set to allow it
|
||||||
|
to do that.
|
||||||
"""]]
|
"""]]
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,75 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 9"""
|
||||||
|
date="2025-01-27T14:46:43Z"
|
||||||
|
content="""
|
||||||
|
Circling back to this, I think the fork in the road is whether this is
|
||||||
|
about git-annex providing this and that feature to support external special
|
||||||
|
remotes that compute, or whether git-annex gets a compute special
|
||||||
|
remote of its own with some simpler/better extension interface
|
||||||
|
than the external special remote protocol.
|
||||||
|
|
||||||
|
Of course, git-annex having its own compute special remote would not
|
||||||
|
preclude other external special remotes that compute. And for that matter,
|
||||||
|
a single external special remote could implement an extension interface.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Thinking about how a generic compute special remote in git-annex could
|
||||||
|
work, multiple instances of it could be initremoted:
|
||||||
|
|
||||||
|
git-annex initremote convertfiles type=compute program=csv-to-xslx
|
||||||
|
git-annex initremote cutvideo type=compute program=ffmpeg-cut
|
||||||
|
|
||||||
|
Here the "program" parameter would cause a program like
|
||||||
|
`git-annex-compute-ffmpeg-cut` to be run to get files from that instance
|
||||||
|
of the compute special remote. The interface could be as simple as it
|
||||||
|
being run with the key that it is requested to compute, and outputting
|
||||||
|
the paths to the all keys it was able to compute. (So allowing for
|
||||||
|
"request one key, receive many".) Perhaps also with some way to indicate
|
||||||
|
progess of the computation.
|
||||||
|
|
||||||
|
It would make sense to store the details of computations in git-annex
|
||||||
|
metadata. And a compute program can use git-annex commands to get files
|
||||||
|
it depends on. Eg, `git-annex-compute-ffmpeg-cut` could run:
|
||||||
|
|
||||||
|
# look up the configured metadata
|
||||||
|
starttime=$(git-annex metadata --get compute-ffmpeg-starttime --key=$requested)
|
||||||
|
endtime=$(git-annex metadata --get compute-ffmpeg-endtime --key=$requested)
|
||||||
|
source=$(git-annex metadata --get compute-ffmpeg-source --key=$requested)
|
||||||
|
|
||||||
|
# get the source video file
|
||||||
|
git-annex get --key=$source
|
||||||
|
git-annex examinekey --format='${objectpath}' $source
|
||||||
|
|
||||||
|
It might be worth formalizing that a given computed key can depend on other
|
||||||
|
keys, and have git-annex always get/compute those keys first. And provide
|
||||||
|
them to the program in a worktree?
|
||||||
|
|
||||||
|
When asked to store a key in the compute special remote, it would verify
|
||||||
|
that the key can be generated by it. Using the same interface as used to
|
||||||
|
get a key.
|
||||||
|
|
||||||
|
This all leaves a chicken and egg problem, how does the user add a computed
|
||||||
|
file if they don't know the key yet?
|
||||||
|
|
||||||
|
The user could manually run the commands that generate the computed file,
|
||||||
|
then `git-annex add` it, and set the metadata. Then `git-annex copy --to`
|
||||||
|
the compute remote would verify if the file can be generated, and add it if
|
||||||
|
so. This seems awkward, but also nice to be able to do manually.
|
||||||
|
|
||||||
|
Or, something like VURL keys could be used, with an interface something
|
||||||
|
like this:
|
||||||
|
|
||||||
|
git-annex addcomputed foo --to ffmpeg-cut
|
||||||
|
--input compute-ffmpeg-source=input.mov
|
||||||
|
--set compute-ffmpeg-starttime=15:00
|
||||||
|
--set compute-ffmpeg-endtime=30:00
|
||||||
|
|
||||||
|
All that would do is generate some arbitrary VURL key or similar,
|
||||||
|
provisionally set the provided metadata (how?), and try to store the key
|
||||||
|
in the compute special remote. If it succeeds, stage an annex pointer
|
||||||
|
and commit the metadata. Since it's a VURL key, storing the key in the
|
||||||
|
compute special remote would also record the hash of the generated file
|
||||||
|
at that point.
|
||||||
|
"""]]
|
||||||
|
|
@ -0,0 +1,14 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="matrss"
|
||||||
|
avatar="http://cdn.libravatar.org/avatar/cd1c0b3be1af288012e49197918395f0"
|
||||||
|
subject="comment 6"
|
||||||
|
date="2025-01-27T15:26:15Z"
|
||||||
|
content="""
|
||||||
|
> > If the PSK were fully contained in the remote string then a third-party getting hold of that string could pretend to be the server
|
||||||
|
|
||||||
|
> I agree this would be a problem, but how would a third-party get ahold of the string though? Remote urls don't usually get stored in the git repository, perhaps you were thinking of some other way.
|
||||||
|
|
||||||
|
My thinking was that git remote URLs usually aren't sensitive information that inherently grant access to a repository, so a construct where the remote URL contains the credentials is just unexpected. A careless user might e.g. put it into a `type=git` special remote or treat it in some other way in which one wouldn't treat a password, without considering the implications. I am not aware of a way in which they could be leaked without user intervention, though.
|
||||||
|
|
||||||
|
Having separate credentials explicitly named as such just seems safer. But in the end this would be the responsibility of the one implementing the p2p transport, anyway.
|
||||||
|
"""]]
|
||||||
Loading…
Add table
Add a link
Reference in a new issue