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 2023-08-14 12:29:53 -04:00
commit afb7703c9f
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 104 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

81
doc/bugs/Sync_fails_when_borg_remote_is_inaccessible.mdwn Normal file
View file

@ -0,0 +1,81 @@
### Please describe the problem.
When a Borg special remote becomes inaccessible, git-annex sync interprets it as
a failed sync. This contrasts from the behavior of git-annex sync when a regular
git-annex repository is not available, where it'll be skipped instead.
My workflow involves backup drives that aren't always connected, which can make
this behavior somewhat confusing to see.
### What steps will reproduce the problem?
1. Create a git-annex and BorgBackup repository.
2. Set up borg repository as a special remote.
3. Move borg repository to another location.
4. Attempt to sync, expecting git-annex to skip the borg repository and exit
with a success regardless. Instead, git-annex exits with a failure.
See below for a script that produces this error for me.
### What version of git-annex are you using? On what operating system?
Using the Guix package on Fedora.
```
git-annex version: 10.20230626
build flags: Assistant Webapp Pairing Inotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
dependency versions: aws-0.23 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.2.5 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 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 X*
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg 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 """
#!/usr/bin/env sh
# Initialize git-annex and borg repository
git init repo
cd repo
git-annex init 'git-annex repository'
borg init --encryption=none ../repo.borg
git-annex initremote borg-repository type=borg borgrepo=../repo.borg
# Sync works as expected when repository is found
echo asdf > testfile
git-annex assist
# Simulate borg repository becoming inaccessible, which results in a failed sync
mv ../repo.borg ../repo.borg.tmp
git-annex sync
"""]]
The following is what `git-annex sync` produces:
```
git-annex sync will change default behavior to operate on --content in a future version of git-annex. Recommend you explicitly use --no-content (or -g) to prepare for that change. (Or you can configure annex.synccontent)
commit
On branch master
nothing to commit, working tree clean
ok
list borg-repository Repository /home/alvin/Downloads/test/repo.borg does not exist.
git-annex: Unable to list contents of borg-repository: user error (borg ["list","--format","{barchive}{NUL}","../repo.borg"] exited 2)
failed
sync: 1 failed
```
### 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)
Been working on an addon command that I'll hopefully get quality enough to be
worth adding to the related software section soon :)

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

@ -0,0 +1,11 @@
Say I have two **unrelated** videos repositories. Say that, by some mistake of history, one was added as the git remote of the other. I somehow managed to clean the git history and disentangle the files between the two repos.
Now git-annex still thinks about that other repository. I can mark it as dead, but it will still have location tracking information for all the files of the other repository.
I know about [[git-annex-forget]]: I'm not sure it's what I want. I do not want to "[throw] away historical data about past locations of files", I would actually *want* to keep historical location data for relevant files. I want to forget a *repository* ever existed.
Is that possible?
Marking it with [[git-annex-dead]] doesn't cut it, from what I understand. In [[tips/what_to_do_when_you_lose_a_repository]], joeyh seemed to say "`dead` is the best we can do", as "the automatic merging used on the git-annex branch tends to re-add lines that are deleted in one repo when merging with another that still has them." But now we have something like `forget`, could that be coerced into forgetting just a subset of stuff?
Thanks! -- [[anarcat]]

12
doc/todo/deleting_a_repository_from_history/comment_1_bcaa591f37f3496c2f7a2e1f06450002._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="nobodyinperson"
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
subject="comment 1"
date="2023-08-10T01:08:16Z"
content="""
This has happened repeatedly to me and I feel your pain. It is especially likely to happen when using submodules, which can sometimes be uninitialized, so when you enter them and modify `git remote`s from there, you're actually messing up the parent repo.
I'm afraid there's no convenient way to purge git annex remotes except marking as `dead` and then `forget --drop-dead`, which loses past location history as well.
What you can do though is trying to manually kick the bad commit out of the git-annex branch (e.g. `git rebase -i`), then force-push the git-annex branch to all remotes. If you miss one remote, the bad commit will be reintroduced somewhen later.
"""]]