7189dfd77d
* webapp: Detect when upgrades are available, and upgrade if the user
desires.
(Only when git-annex is installed using the prebuilt binaries
from git-annex upstream, not from eg Debian.)
* assistant: Detect when the git-annex binary is modified or replaced,
and either prompt the user to restart the program, or automatically
restart it.
* annex.autoupgrade configures both the above upgrade behaviors.
* Added support for quvi 0.9. Slightly suboptimal due to limitations in its
interface compared with the old version.
* Bug fix: annex.version did not get set on automatic upgrade to v5 direct
mode repo, so the upgrade was performed repeatedly, slowing commands down.
* webapp: Fix bug that broke switching between local repositories
that use the new guarded direct mode.
* Android: Fix stripping of the git-annex binary.
* Android: Make terminal app show git-annex version number.
* Android: Re-enable XMPP support.
* reinject: Allow to be used in direct mode.
* Futher improvements to git repo repair. Has now been tested in tens
of thousands of intentionally damaged repos, and successfully
repaired them all.
* Allow use of --unused in bare repository.
# 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`
|