b6d46c212e
* unannex, uninit: Avoid committing after every file is unannexed,
for massive speedup.
* --notify-finish switch will cause desktop notifications after each
file upload/download/drop completes
(using the dbus Desktop Notifications Specification)
* --notify-start switch will show desktop notifications when each
file upload/download starts.
* webapp: Automatically install Nautilus integration scripts
to get and drop files.
* tahoe: Pass -d parameter before subcommand; putting it after
the subcommand no longer works with tahoe-lafs version 1.10.
(Thanks, Alberto Berti)
* forget --drop-dead: Avoid removing the dead remote from the trust.log,
so that if git remotes for it still exist anywhere, git annex info
will still know it's dead and not show it.
* git-annex-shell: Make configlist automatically initialize
a remote git repository, as long as a git-annex branch has
been pushed to it, to simplify setup of remote git repositories,
including via gitolite.
* add --include-dotfiles: New option, perhaps useful for backups.
* Version 5.20140227 broke creation of glacier repositories,
not including the datacenter and vault in their configuration.
This bug is fixed, but glacier repositories set up with the broken
version of git-annex need to have the datacenter and vault set
in order to be usable. This can be done using git annex enableremote
to add the missing settings. For details, see
http://git-annex.branchable.com/bugs/problems_with_glacier/
* Added required content configuration.
* assistant: Improve ssh authorized keys line generated in local pairing
or for a remote ssh server to set environment variables in an
alternative way that works with the non-POSIX fish shell, as well
as POSIX shells.
# imported from the archive
93 lines
3.8 KiB
Markdown
93 lines
3.8 KiB
Markdown
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
|
|
`.git/annex/objects/`. Direct mode gets rid of the symlinks.
|
|
|
|
The advantage of direct mode is that you can access files directly,
|
|
including modifying them. The disadvantage is that most regular git
|
|
commands cannot be used in a direct mode repository.
|
|
|
|
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.
|
|
* Windows always uses direct mode.
|
|
|
|
## enabling (and disabling) direct mode
|
|
|
|
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.
|
|
|
|
To start using direct mode:
|
|
|
|
git annex direct
|
|
|
|
To stop using direct mode:
|
|
|
|
git annex indirect
|
|
|
|
## safety of using direct mode
|
|
|
|
With direct mode, you're operating without large swathes of git-annex's
|
|
carefully constructed safety net, which ensures that past versions of
|
|
files are preserved and can be accessed.
|
|
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:
|
|
|
|
git annex untrust .
|
|
|
|
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.
|
|
|
|
## use a direct mode repository
|
|
|
|
You can use most git-annex commands as usual in a direct mode repository.
|
|
|
|
Direct mode also works well with the git-annex assistant.
|
|
|
|
The most important command to use in a direct mode repository is `git annex
|
|
sync`. This will commit any files you have run `git annex add` on, as well
|
|
as files that were added earlier and have been modified. It will push
|
|
the changes to other repositories for `git annex sync` there to pick up,
|
|
and will pull and merge any changes made on other repositories into the
|
|
local repository.
|
|
|
|
## what doesn't work in direct mode
|
|
|
|
A very few git-annex commands don't work in direct mode, and will refuse
|
|
to do anything. For example, `git annex unlock` doesn't make sense in
|
|
direct mode.
|
|
|
|
As for git commands, direct mode prevents using any git command that would
|
|
modify or access the work tree. So you cannot `git commit` or `git pull`
|
|
(use `git annex sync` for both instead), or run `git status` (use `git
|
|
annex status` instead). These git commands will complain "fatal: This
|
|
operation must be run in a work tree".
|
|
|
|
The reason for this is that git doesn't understand how git-annex uses the
|
|
work tree in direct mode. Where git expects the symlinks that get checked
|
|
into git to be checked out in the work tree, direct mode instead replaces
|
|
them with the actual content of files, as managed by git-annex.
|
|
|
|
There are still lots of git commands you can use in direct mode. For
|
|
example, you can run `git log` on files, run `git push`, `git fetch`,
|
|
`git config`, `git remote add` etc.
|
|
|
|
## forcing git to use the work tree in direct mode
|
|
|
|
This is for experts only. You can lose data doing this, or check enormous
|
|
files directly into your git repository, and it's your fault if you do!
|
|
Also, there should be no good reason to need to do this, ever.
|
|
|
|
Ok, with the warnings out of the way, all you need to do to make any
|
|
git command access the work tree in direct mode is pass it
|
|
`-c core.bare=false`
|