2012-12-12 19:36:00 +00:00
|
|
|
Normally, git-annex repositories consist of symlinks that are checked into
|
|
|
|
git, and in turn point at the content of large files that is stored in
|
2013-01-01 18:01:47 +00:00
|
|
|
`.git/annex/objects/`. Direct mode gets rid of the symlinks.
|
2012-12-12 19:36:00 +00:00
|
|
|
|
|
|
|
The advantage of direct mode is that you can access files directly,
|
|
|
|
including modifying them. The disadvantage is that most regular git
|
|
|
|
commands cannot safely be used, and only a subset of git-annex commands
|
|
|
|
can be used.
|
|
|
|
|
2013-02-15 22:22:23 +00:00
|
|
|
Normally, git-annex repositories start off in indirect mode. With some
|
|
|
|
exceptions:
|
|
|
|
|
|
|
|
* Repositories created by the [[assistant]] use direct mode by default.
|
|
|
|
* Repositories on FAT and other less than stellar filesystems
|
|
|
|
that don't support things like symlinks will be automatically put
|
|
|
|
into direct mode.
|
2013-05-13 17:46:03 +00:00
|
|
|
* Windows always uses direct mode.
|
2013-01-01 18:01:47 +00:00
|
|
|
|
2012-12-13 19:44:56 +00:00
|
|
|
## enabling (and disabling) direct mode
|
2012-12-12 19:36:00 +00:00
|
|
|
|
2012-12-13 19:44:56 +00:00
|
|
|
Any repository can be converted to use direct mode at any time, and if you
|
|
|
|
decide not to use it, you can convert back to indirect mode just as easily.
|
|
|
|
Also, you can have one clone of a repository using direct mode, and another
|
|
|
|
using indirect mode; direct mode interoperates.
|
2012-12-12 19:36:00 +00:00
|
|
|
|
2012-12-13 19:44:56 +00:00
|
|
|
To start using direct mode:
|
|
|
|
|
|
|
|
git annex direct
|
|
|
|
|
|
|
|
To stop using direct mode:
|
|
|
|
|
|
|
|
git annex indirect
|
|
|
|
|
2013-01-16 19:35:06 +00:00
|
|
|
## safety of using direct mode
|
|
|
|
|
2012-12-13 19:44:56 +00:00
|
|
|
With direct mode, you're operating without large swathes of git-annex's
|
2013-01-16 19:35:06 +00:00
|
|
|
carefully constructed safety net, which ensures that past versions of
|
|
|
|
files are preserved and can be accessed (until you dropunused them).
|
|
|
|
With direct mode, any file can be edited directly, or deleted at any time,
|
|
|
|
and there's no guarantee that the old version is backed up somewhere else.
|
|
|
|
|
|
|
|
So if you care about preserving the history of files, you're strongly
|
|
|
|
encouraged to tell git-annex that your direct mode repository cannot be
|
|
|
|
trusted to retain the content of a file. To do so:
|
2012-12-13 19:44:56 +00:00
|
|
|
|
|
|
|
git annex untrust .
|
2012-12-12 19:36:00 +00:00
|
|
|
|
2013-01-16 19:35:06 +00:00
|
|
|
On the other hand, if you only care about the current versions of files,
|
|
|
|
and are using git-annex with direct mode to keep files synchronised between
|
|
|
|
computers, and manage your files, this should not be a concern for you.
|
|
|
|
|
2012-12-12 19:36:00 +00:00
|
|
|
## use a direct mode repository
|
|
|
|
|
2013-01-06 21:22:02 +00:00
|
|
|
You can use most git-annex commands as usual in a direct mode repository.
|
2013-01-16 19:35:06 +00:00
|
|
|
A very few commands don't work in direct mode, and will refuse to do anything.
|
2012-12-25 20:18:59 +00:00
|
|
|
|
2013-01-06 21:22:02 +00:00
|
|
|
Direct mode also works well with the git-annex assistant.
|
2012-12-12 19:36:00 +00:00
|
|
|
|
2013-01-16 23:52:41 +00:00
|
|
|
You can use `git commit --staged`, or plain `git commit`.
|
|
|
|
But not `git commit -a`, or `git commit <file>` ..
|
|
|
|
that'd commit whole large files into git!
|
2012-12-12 19:36:00 +00:00
|
|
|
|
|
|
|
## what doesn't work in direct mode
|
|
|
|
|
2013-01-16 23:52:41 +00:00
|
|
|
`git annex status` shows incomplete information. A few other commands,
|
2013-01-06 21:22:02 +00:00
|
|
|
like `git annex unlock` don't make sense in direct mode and will refuse to
|
|
|
|
run.
|
2012-12-12 19:36:00 +00:00
|
|
|
|
|
|
|
As for git commands, you can probably use some git working tree
|
|
|
|
manipulation commands, like `git checkout` and `git revert` in useful
|
|
|
|
ways... But beware, these commands can replace files that are present in
|
|
|
|
your repository with broken symlinks. If that file was the only copy you
|
|
|
|
had of something, it'll be lost.
|
|
|
|
|
2013-01-16 19:35:06 +00:00
|
|
|
This is one more reason it's wise to make git-annex untrust your direct mode
|
2012-12-12 19:36:00 +00:00
|
|
|
repositories. Still, you can lose data using these sort of git commands, so
|
2013-01-06 21:22:02 +00:00
|
|
|
use extreme caution.
|