From 2f25b8360fc64a97f01d724ac28c942e06a8c8d3 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 10 Dec 2015 11:15:06 -0400 Subject: [PATCH] response --- ..._499f3553c4efc35e54f121a7d4abc029._comment | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 doc/devblog/day_339_smudging_out_direct_mode/comment_5_499f3553c4efc35e54f121a7d4abc029._comment diff --git a/doc/devblog/day_339_smudging_out_direct_mode/comment_5_499f3553c4efc35e54f121a7d4abc029._comment b/doc/devblog/day_339_smudging_out_direct_mode/comment_5_499f3553c4efc35e54f121a7d4abc029._comment new file mode 100644 index 0000000000..b4cbe978e2 --- /dev/null +++ b/doc/devblog/day_339_smudging_out_direct_mode/comment_5_499f3553c4efc35e54f121a7d4abc029._comment @@ -0,0 +1,30 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 5""" + date="2015-12-10T15:00:52Z" + content=""" +I'm concerned about that too. But it may be possible to finesse it, +when git-annex is running on a crippled filesystem, it may be able to +unlock all files as it gets content for them, producing a local fork. + +The first difficulty would be avoiding or autoresolving conflicts +between locked and unlocked when merging changes into that fork. I think +this is very tractable; such a conflict comes down mostly to the symlink +bit in the tree object. + +The real difficulty would be that any pushes from that fork would include +its change converting all files to unlocked. Although it's fairly mechanical +to convert such a commit into one that doesn't unlock files, so perhaps +that could be automated somehow on push or merge. + +There's also a small and probably easy to implement git change that +would avoid all this complexity: If git's smudge filters were optionally +able to run on the link-text of symlinks, then a file could be unlocked +locally without changing what's in the repo and all the smudge stuff +would still work on it. + +Crippled filesystems aside, I think there's value in being able to unlock +files across clones of a repo. For example, a repo could have a workflow +where the files for the current episiode/experiment/whatever start out +unlocked and are locked once it's complete. +"""]] -- 2.30.2