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

This commit is contained in:
Joey Hess 2021-06-25 12:06:49 -04:00
commit f57804e72c
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 50 additions and 0 deletions

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="strmd"
avatar="http://cdn.libravatar.org/avatar/035707b9756129bbdea6b36a7f7b38d3"
subject="comment 8"
date="2021-06-25T15:07:54Z"
content="""
Using my M1 Air a lot more these days, not having git-annex is a pain. The Homebrew formula dependencies all have ARM bottles at this point, but building from source fails (criterion-measurement-0.1.2.0). Anyone with ideas on how to end up with a working Rosetta 2 setup? My previous experiments were a mess (see above), no doubt partly due to an environment where multiple versions of various components are conflicting with each other.
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="thanks "
date="2021-06-24T16:40:48Z"
content="""
Thanks for doing the benchmarking; seems like git-annex's batching of operations already captures whatever speedup de-synchronizing could give.
"""]]

View file

@ -0,0 +1,6 @@
From [another thread](https://git-annex.branchable.com/todo/add_option_to_use_sqlite__39__s_synchronous__61__OFF/#comment-dbc9fdf5fd6d73f3e628bfe94b2a43a2):
>Quite possible there are situations where it fails to recover the lost information and does something annoying. But like I said, such situations can already happen
Maybe, there are some simple ways to harden git-annex against possible weirdness following abrupt interruptions? E.g. using flag files to detect when a prior operation got interrupted,
and rebuilding the sqlite dbs from git data. Or tagging sqlite records with the timestamp of their creation, and not using the data if the relevant worktree files got modified since then.

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="Lukey"
avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
subject="comment 2"
date="2021-06-24T17:43:36Z"
content="""
The idea is to solve the conflicts in a similar way to conflicts in annexed files. I.e. by creating two files file.version-a and file.version-b.
"""]]

View file

@ -0,0 +1,16 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="resolving merge conflicts"
date="2021-06-24T18:03:40Z"
content="""
\"Small files\" here means \"non-annexed files\", right?
Whether a file is annexed, and whether its merge conflicts should be auto-resolved by creating two files `file.version-a` and `file.version-b`, seem like orthogonal things.
One might check small binary files directly into git, and one might annex source code files e.g. just for the simplicity of annexing everything (as [[DataLad|projects/datalad]] does or at least used to).
So, maybe, `.gitattributes` should control which files' merge conflicts get auto-resolved?
"""]]