diff options
author | Joey Hess <joeyh@joeyh.name> | 2015-12-10 11:15:06 -0400 |
---|---|---|
committer | Joey Hess <joeyh@joeyh.name> | 2015-12-10 11:15:06 -0400 |
commit | 894d4fbcb05f0962a372775902c0c14b32cc82c6 (patch) | |
tree | c5a60e835dfe51e348610c4998f7361514031034 /doc | |
parent | e762d5e8b1d62210fb27f15729f20cb77f6b17c3 (diff) |
response
Diffstat (limited to 'doc')
-rw-r--r-- | doc/devblog/day_339_smudging_out_direct_mode/comment_5_499f3553c4efc35e54f121a7d4abc029._comment | 30 |
1 files changed, 30 insertions, 0 deletions
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 000000000..b4cbe978e --- /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. +"""]] |