maybe call it unlock and not checkout

It'd be confusing to have a git-annex subcommand with the same name as a
git subcommand.
This commit is contained in:
Joey Hess 2010-11-09 15:11:45 -04:00
parent 75d2925082
commit d56feda25d
4 changed files with 19 additions and 18 deletions

6
debian/changelog vendored
View file

@ -1,8 +1,8 @@
git-annex (0.04) UNRELEASED; urgency=low
* Add checkout subcommand, which allows checking out file content
in preparation of changing it.
* Add uncheckout subcommand.
* Add unlock subcommand, which replaces the symlink with a copy of
the file's content in preparation of changing it.
* Add lock subcommand.
* Add build dep on libghc6-testpack-dev.
* Add annex.version, which will be used to automate upgrades
between incompatable versions.

View file

@ -81,9 +81,10 @@ Many git-annex subcommands will stage changes for later `git commit` by you.
git-annex may refuse to drop content if the backend does not think
it is safe to do so, typically because of the setting of annex.numcopies.
* checkout [path ...]
* unlock [path ...]
Checks out annexed files so they can be modified. This replaces the
Normally, the content of annexed files is protected from being changed.
Unlocking a annexed file allows it to be modified. This replaces the
symlink for each specified file with a copy of the file content.
When you `git commit`, the file, the new content is injected back into
the annex.
@ -102,10 +103,10 @@ Many git-annex subcommands will stage changes for later `git commit` by you.
and sets up `.gitattributes` and the pre-commit hook.
This is an optional, but recommended step.
* uncheckout [path ...]
* lock [path ...]
Use this to undo a checkout command if you don't want to modify
the checked out files, or have made modifications you want to discard.
Use this to undo an unlock command if you don't want to modify
the files, or have made modifications you want to discard.
* unannex [path ...]

View file

@ -4,4 +4,4 @@ In particular, while files can be added using it, git-annex will not notice
when their content changes, and will not create a new key for the new sha1
of the net content.
[[done]]; use checkout subcommand
[[done]]; use unlock subcommand and commit changes with git

View file

@ -192,23 +192,23 @@ makes it very easy.
## modifying annexed files
Normally, the content of files in the annex cannot be modified.
In order to modify a file, it should first be checked out:
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 checkout my_cool_big_file
checkout my_cool_big_file (copying...) ok
# git annex unlock my_cool_big_file
unlock my_cool_big_file (copying...) ok
Checking a file out 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.
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 a checked-out file, and add its new content
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 uncheckout subcommand to undo the checkout.
modifications, just use the lock subcommand.
## using the URL backend