From 879ac0b713ca0c8d9466d8d40892c9c622b01c41 Mon Sep 17 00:00:00 2001 From: Ilya_Shlyakhter Date: Thu, 24 Jun 2021 16:40:48 +0000 Subject: [PATCH 1/5] Added a comment: thanks --- ...comment_4_6601e9d3004c968d9f6511804e325b55._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/add_option_to_use_sqlite__39__s_synchronous__61__OFF/comment_4_6601e9d3004c968d9f6511804e325b55._comment diff --git a/doc/todo/add_option_to_use_sqlite__39__s_synchronous__61__OFF/comment_4_6601e9d3004c968d9f6511804e325b55._comment b/doc/todo/add_option_to_use_sqlite__39__s_synchronous__61__OFF/comment_4_6601e9d3004c968d9f6511804e325b55._comment new file mode 100644 index 0000000000..46fba79895 --- /dev/null +++ b/doc/todo/add_option_to_use_sqlite__39__s_synchronous__61__OFF/comment_4_6601e9d3004c968d9f6511804e325b55._comment @@ -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. + + +"""]] From fb2e418fa2c01f69e8a014d46b48c41b61485105 Mon Sep 17 00:00:00 2001 From: Lukey Date: Thu, 24 Jun 2021 17:43:36 +0000 Subject: [PATCH 2/5] Added a comment --- ...comment_2_4af09b9b24fc39bb702a5db05638a1c1._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/resolve_merge_conflicts_with_smallfiles/comment_2_4af09b9b24fc39bb702a5db05638a1c1._comment diff --git a/doc/todo/resolve_merge_conflicts_with_smallfiles/comment_2_4af09b9b24fc39bb702a5db05638a1c1._comment b/doc/todo/resolve_merge_conflicts_with_smallfiles/comment_2_4af09b9b24fc39bb702a5db05638a1c1._comment new file mode 100644 index 0000000000..aa467a9f1b --- /dev/null +++ b/doc/todo/resolve_merge_conflicts_with_smallfiles/comment_2_4af09b9b24fc39bb702a5db05638a1c1._comment @@ -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. + + +"""]] From 7ad95210d19bf21d76da7a76142876fc9a537045 Mon Sep 17 00:00:00 2001 From: Ilya_Shlyakhter Date: Thu, 24 Jun 2021 18:03:40 +0000 Subject: [PATCH 3/5] Added a comment: resolving merge conflicts --- ...t_3_9098b3f365af6fe0692cf02b31fd6dee._comment | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/todo/resolve_merge_conflicts_with_smallfiles/comment_3_9098b3f365af6fe0692cf02b31fd6dee._comment diff --git a/doc/todo/resolve_merge_conflicts_with_smallfiles/comment_3_9098b3f365af6fe0692cf02b31fd6dee._comment b/doc/todo/resolve_merge_conflicts_with_smallfiles/comment_3_9098b3f365af6fe0692cf02b31fd6dee._comment new file mode 100644 index 0000000000..66d5ecd860 --- /dev/null +++ b/doc/todo/resolve_merge_conflicts_with_smallfiles/comment_3_9098b3f365af6fe0692cf02b31fd6dee._comment @@ -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? + + + +"""]] From 27df3f8e8826cca694193336f575de77a7417f08 Mon Sep 17 00:00:00 2001 From: Ilya_Shlyakhter Date: Thu, 24 Jun 2021 18:16:43 +0000 Subject: [PATCH 4/5] added suggestion re: hardening git-annex against interruptions --- doc/todo/harden_against_interruptions.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 doc/todo/harden_against_interruptions.mdwn diff --git a/doc/todo/harden_against_interruptions.mdwn b/doc/todo/harden_against_interruptions.mdwn new file mode 100644 index 0000000000..cd38f9b457 --- /dev/null +++ b/doc/todo/harden_against_interruptions.mdwn @@ -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. From 3eb68df9d594fd3cfab225379e1fcf1d86c0b348 Mon Sep 17 00:00:00 2001 From: strmd Date: Fri, 25 Jun 2021 15:07:55 +0000 Subject: [PATCH 5/5] Added a comment --- .../comment_8_4620929361fb5ad8faea15ed3905d67f._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/Apple_M1_Silicon/comment_8_4620929361fb5ad8faea15ed3905d67f._comment diff --git a/doc/forum/Apple_M1_Silicon/comment_8_4620929361fb5ad8faea15ed3905d67f._comment b/doc/forum/Apple_M1_Silicon/comment_8_4620929361fb5ad8faea15ed3905d67f._comment new file mode 100644 index 0000000000..b367ad6fc5 --- /dev/null +++ b/doc/forum/Apple_M1_Silicon/comment_8_4620929361fb5ad8faea15ed3905d67f._comment @@ -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. +"""]]