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 2021-05-24 16:31:58 -04:00
commit 125a28c58e
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
10 changed files with 148 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
doc/bugs/Git_repos_corrupt_themselves/comment_7_54aed251ddb9df1c8164a25240e1533f._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Atemu"
avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
subject="comment 7"
date="2021-05-22T17:02:07Z"
content="""
What could I do to get to the bottom of this? Is there a verbose logging feature for the assistant that could give more insight?
"""]]

8
doc/bugs/Git_repos_corrupt_themselves/comment_8_a1131917149dd07ec73367e7cbc3b3f2._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Lukey"
avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
subject="comment 8"
date="2021-05-22T17:19:19Z"
content="""
You could run the equivalent of `strace` for mac os and make it log every syscall of git-annex assistant and it's children. This would show which `git` action corrupts the repo and how.
"""]]

8
doc/bugs/Git_repos_corrupt_themselves/comment_9_033def91d2a30f1cee498fabbfe5d37f._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Atemu"
avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
subject="comment 9"
date="2021-05-22T17:31:01Z"
content="""
This also happens on Linux, so I'd rather use `strace` itself but I think it'd be extremely hard to spot anything useful in that and probably is not worth the performance cost.
"""]]

12
doc/bugs/delayadd_doesn__39__t_work/comment_4_dbe41188bc6650418b68f52ec479fc11._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="Atemu"
avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
subject="comment 4"
date="2021-05-22T09:55:31Z"
content="""
You are quite correct, the minimal test case works just as expected when the config is applied *before* running the daemon.
`delayadd` has been in my actual repo's config for many months now and has seen countless daemon restarts however, so that can't be my actual problem unfortunately.
Now that I have a working repo, I will try to break it like I did with my regular repo.
"""]]

32
doc/bugs/delayadd_doesn__39__t_work/comment_5_31a194407e433b17450725170552b8f7._comment Normal file
View file

@ -0,0 +1,32 @@
[[!comment format=mdwn
username="Atemu"
avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
subject="comment 5"
date="2021-05-22T10:20:35Z"
content="""
I found the culprit: largefiles.
I use
```
* annex.largefiles=mimeencoding=binary
```
in my documents repo because I need to efficiently store lots of text and diff, merge etc. properly.
Here are the revised repro steps:
```
git init test
cd test
git annex init
git config annex.delayadd 5
echo '* annex.largefiles=mimeencoding=binary' > .gitattributes
git add .
git commit -m \"gitattributes: largefiles\"
git annex assistant
echo `date` > test
git log --patch
```
The date of the commit should be the date in the file +5s.
"""]]

15
doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_12_9315e2d9ecc6224b2695ef319676413b._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="defining preferred content state"
date="2021-05-23T20:39:23Z"
content="""
Thanks @joeyh for working on this.
Is the following understanding of preferred content expressions accurate:
* the expression is a predicate on file paths, not on keys. Expressions that check the property of a key (e.g. numcopies) are evaluated for each file path on the key it uses.
* a given key is wanted in a repo if the preferred content expression is true for *any* file path which uses the key
Also, if the above if correct, is \"any file path which uses the key\" defined the same way as in [[git-annex-unused]]?
"""]]

16
doc/forum/Questions_about_borg_special_remotes/comment_2_5c10ff05b8e1714aa9b413d6b01e275e._comment Normal file
View file

@ -0,0 +1,16 @@
[[!comment format=mdwn
username="strmd"
avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
subject="comment 2"
date="2021-05-22T05:16:44Z"
content="""
Well, that certainly explains it. Not only that, it makes perfect sense. The borg repo in question has about a hundred archives so I soon grew tired. ```BORG_PASSPHRASE``` seems obvious in retrospect, of course the GUI does that for me in my day-to-day use.
Trying to use some of the really clever combinations on offer is challenging to a novice user. I sometimes feel like my ambition is to be a half-decent conductor, only I'm periodically also expected to step down and tune the harpsichord. Mind you, this isn't criticism – it's one of the principles that makes git-annex so great. borg is a solo performer, adding it to the ensemble is my choice and making it blend well with the rest of the instruments is up to me.
On third, careful look, I don't believe there's any error on the tips page.
Thanks!
"""]]

37
doc/forum/distributed_borg.mdwn Normal file
View file

@ -0,0 +1,37 @@
The Borg special remote is indeed an exciting next step for this amazing
project. I’m currently testing it with a small team. For remote collaboration,
each of us has provisioned:
- one workstation with a git-annex repo (accessible only to the workstation user)
- one server (NAS) with a Borg repo (accessible to all team members)
The idea was to implement a basic distributed topology by adding all the Borg
repos as special remotes to all the git-annex repos. With such an implementation,
a typical workflow would be:
1. A team member:
**(a)** commits a change to the git-annex repo on the member’s own workstation,
**(b)** creates an archive of the updated git-annex repo in each of the Borg
repos, and
**(c)** informs the member’s own git-annex repo of the new Borg archives by running `git annex sync`.
2. All other team members inform their respective git-annex repos of the new
Borg archives by simply running `git annex sync`.
Step 1 worked, but Step 2 did not, so as a workaround, we added a bare
git-annex repo alongside the Borg repo on each server, then added all the new
bare repos as remotes to each of our respective workstation repos. It works
but is less than ideal.
My simplified question: can two git-annex repos share a Borg special remote?
Joey commented back in December: “The Remote interface recently got
importKey, which gets us unexpectedly a lot closer to making git-annex import
--from borg a reality!” However, I’ve struggled to find any other clues.
Potentially related issues (all of which appear to have been addressed):
- [sync --content with borg does not get content](https://git-annex.branchable.com/todo/sync_--content_with_borg_does_not_get_content/)
- [borg sync tree not grafted](https://git-annex.branchable.com/todo/borg_sync_tree_not_grafted/)
- [use same vector clock for content identifier updates in import](https://git-annex.branchable.com/todo/use_same_vector_clock_for_content_identifier_updates_in_import/)
Thanks!

3
doc/install/OpenBSD.mdwn
View file

@ -1,2 +1 @@
git-annex is [in OpenBSD ports](https://openports.pl/path/devel/git-annex)
(in current), and can be installed with `pkg_add git-annex`
git-annex is [in OpenBSD ports](https://openports.pl/path/devel/git-annex), and can be installed with `pkg_add git-annex`

11
doc/todo/add_--json-progress_to_fsck_--json/comment_1_170acd9fc5b5a40ae22de0bf418b424c._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="parhuzamos"
avatar="http://cdn.libravatar.org/avatar/79ed445f40e89bd8ba696bab3942ec56"
subject="comment 1"
date="2021-05-24T09:33:50Z"
content="""
Is this possible? Or makes no sense? Do you plan implementing this?
Thank you,
Bence
"""]]