git-annex/ walkthrough/ modifying annexed files

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.

feature request: unlock --drop

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.

Comment by http://yarikoptic.myopenid.com/ — Wed Oct 29 14:05:27 2025
sorta why git-annex exists in the first place -- not only the slow index

> Git wants to first stage the entire contents of the file in its index. That can be slow for big files (sorta why git-annex exists in the first place)

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

- they are either not under my control (e.g., web URLs),
- or because it's not convenient to hold a Git repo there (an external disk/DVD with files can be viewed easily by a human, but imposing a Git repo structure on it would either at least double the consume space: for the history of the commits and for the working dir, or make it "unreadable" for a human, if it is a bare repo);
- or because it's nearly impossible to put a Git repo on a storage like peer networks without special tools.

Comment by http://lj.rossia.org/users/imz/ — Wed Oct 29 14:05:27 2025
Comments on this page are closed.