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

comment

Browse source
This commit is contained in:
Joey Hess 2022-09-09 15:15:54 -04:00
parent 511e711bed
commit 247c0e59cf
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 32 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

32
doc/forum/Unlocked_mode_without_data_also_under_.git__47__annex__63__/comment_1_d35829cd466139e0e77a79c251a79ad8._comment Normal file
View file

@ -0,0 +1,32 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2022-09-09T18:54:08Z"
content="""
Suppose git-annex did behave that way. Now suppose that you ran:
git config annex.largefiles 'include=*'
git add largefile
git commit -m 'added a large file to git-annex (unlocked)'
git stash
Then git would have deleted the only copy of largefile, which
was the one stored in the working tree. You would have lost data.
The hard links, annoying as they are, avoid this problem.
> But as we know, when we modify a file, it invalidates its checksum
Right, and if you're going to be running things that open and modify
files, then it is not safe to set annex.thin.
"echo foo > largefile" will modify the file and lose the original version.
The difference is that you have to run something that does usually
modify the file to lose data (with annex.thin set).
Running a git command that is normally entirely safe will not lose data.
So the user of annex.thin only needs to keep in mind that some things that
would usually modify a file will lose the previous version of it,
unless they've copied it to another remote. They don't have to live in fear
of running a command that is usually safe and reversable and that causing
data loss.
"""]]