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

update for modifying files

Browse source
This commit is contained in:
Joey Hess 2010-11-10 13:27:52 -04:00
parent 43412419ea
commit ee6052cbf8
1 changed files with 45 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

65
doc/walkthrough.mdwn
View file

@ -139,6 +139,51 @@ But `other.iso` looks to have never been copied to anywhere else, so if
it's something you want to hold onto, you'd need to transfer it to it's something you want to hold onto, you'd need to transfer it to
some other repository before dropping it. some other repository before dropping it.
## modifying annexed files
Normally, the content of files in the annex is prevented from being modified.
# echo oops > my_cool_big_file
bash: my_cool_big_file: Permission deined
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
They 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 `git commit`, git-annex's pre-commit hook will automatically
notice that you are committing an unlocked file, and add its new content
to the annex. The file will be replaced with a symlink to the new content,
and this symlink is what gets committed to git in the end.
# 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
(Recording state in git...)
[master 64cda67] changed an annexed file
2 files changed, 2 insertions(+), 1 deletions(-)
create mode 100644 .git-annex/SHA1:0b1d8616d0238cb9418a0e0a649bdad2e9e7faae.log
There is one problem with using `git commit` like this: 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). So, the
automatic handling on commit is a nice safety feature, since it prevents
the file content being accidentially commited into git. But when working with
big files, it's faster to explicitly add them to the annex yourself
before committing.
# echo "now smaller, but even cooler yet" > my_cool_big_file
# git annex add my_cool_big_file
add my_cool_big_file ok
# git commit my_cool_big_file -m "changed an annexed file"
## using ssh remotes ## using ssh remotes
So far in this walkthrough, git-annex has been used with a remote So far in this walkthrough, git-annex has been used with a remote
@ -190,26 +235,6 @@ makes it very easy.
WORM:1274316523:86050597:hackity_hack_and_kax 100% 82MB 199.1KB/s 07:02 WORM:1274316523:86050597:hackity_hack_and_kax 100% 82MB 199.1KB/s 07:02
ok ok
## modifying annexed files
Normally, the content of files in the annex is prevented from being modified.
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
They 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.
When you `git commit`, git-annex's pre-commit hook will automatically
notice that you are committing an unlocked file, and add its new content
to the annex. The file will be replaced with a symlink to the new content,
and this symlink is what gets committed to git.
If you decide you don't need to modify the file after all, or want to discard
modifications, just use the lock subcommand.
## using the URL backend ## using the URL backend
git-annex has multiple key-value [[backends]]. So far this walkthrough has git-annex has multiple key-value [[backends]]. So far this walkthrough has