Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
commit
f57804e72c
5 changed files with 50 additions and 0 deletions
|
@ -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.
|
||||
"""]]
|
|
@ -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.
|
||||
|
||||
|
||||
"""]]
|
6
doc/todo/harden_against_interruptions.mdwn
Normal file
6
doc/todo/harden_against_interruptions.mdwn
Normal 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.
|
|
@ -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.
|
||||
|
||||
|
||||
"""]]
|
|
@ -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?
|
||||
|
||||
|
||||
|
||||
"""]]
|
Loading…
Reference in a new issue