From 2e6aff74c20da4e67af7a887a0827fec5dfd8a24 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 26 Oct 2018 13:44:55 -0400 Subject: [PATCH] response --- ...t_2_bae3f3303d61126a337f2dac71681e1d._comment | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/devblog/day_550__a_plan_to_finish_v6/comment_2_bae3f3303d61126a337f2dac71681e1d._comment diff --git a/doc/devblog/day_550__a_plan_to_finish_v6/comment_2_bae3f3303d61126a337f2dac71681e1d._comment b/doc/devblog/day_550__a_plan_to_finish_v6/comment_2_bae3f3303d61126a337f2dac71681e1d._comment new file mode 100644 index 0000000000..e5af419f67 --- /dev/null +++ b/doc/devblog/day_550__a_plan_to_finish_v6/comment_2_bae3f3303d61126a337f2dac71681e1d._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2018-10-26T17:41:14Z" + content=""" +Well, `git annex add -J` works of course.. `git add` doesn't have a way to +parallelize, nor does git checkout. + +It might be useful to parallelize `git annex smudge --update` which updates +unlocked files in the work tree. I guess it should already be mostly disk +bound when it's copying files and parallalizing that would likely only +worsten things due to seeking (on spinning rust), +but it may have some parallizable overhead when it's making annex.thin hardlinks. +It would need to be controlled via a git config flag or something since +it gets run internally. +"""]]