mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions 1

hmm

Browse source
This commit is contained in:
Joey Hess 2016-10-17 17:12:31 -04:00
parent 0869340c70
commit 7d6e805d28
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
1 changed files with 20 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

20
doc/todo/unlock_--read-only/comment_2_1658f775ef9340e65711512049085dd7._comment Normal file
View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2016-10-17T21:07:31Z"
content="""
Actually, yoh is right: read-only would be sufficient protection here.
Because, with annex.thin, the worktree file is a hard link to the annex
object, and the annex object lives in a mode 400 directory. So, even if the
file is deleted and a new version renamed into place, the annex object will
still have captured the old version.
Still don't like the self-contradition of "unlock read-only".
Of course, you can do this yourself:
git annex unlock file
chmod 400 file
So I wonder if there's any need for a git-annex command to do this.
"""]]