Normally, the content of files in the annex is prevented from being modified.
That's a good thing, because it might be the only copy, you wouldn't want to lose it in a fumblefingered mistake.
$ echo oops > my_cool_big_file
bash: my_cool_big_file: Permission denied
In order to modify a file, it should first be unlocked.
$ git annex unlock my_cool_big_file
unlock my_cool_big_file (copying...) ok
That replaces the symlink that normally points at its content with a copy of the content. You can then modify the file like any regular file. Because it is a regular file.
(If you decide you don't need to modify the file after all, or want to discard
modifications, just use git annex lock
.)
When you commit an unlocked file, all that gets committed to git is a pointer to the content. The content of the file is stored by git-annex.
$ echo "now smaller, but even cooler" > my_cool_big_file
$ git commit my_cool_big_file -m "changed an annexed file"
add my_cool_big_file ok
[master 64cda67] changed an annexed file
1 files changed, 1 insertions(+), 1 deletions(-)
For more details on working with unlocked files vs the regular locked files, see unlocked files.
ATM unlock copies original file for modifications, so that original copy remains under annex and possibly to-be-edited copy created. But if I am "unlock"ing file I might simply not be interested in a previous copy and want to maintain only a single (possibly edited) new copy. What if there was a mode where the actual file is simply moved into "unlocked" location for editing, thus effectively dropping the actual content from git annex. That would allow to not inquire lengthy copying/wasting local space. If then I would need a previous copy I would just "get" it again.
I think that git-annex's usefulness is not only because of the Git's index overhead: I like its idea because it will help track the copies in the "special remotes", which are not Git because