| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
repository configuration settings stored in the git-annex branch.
Incomplete; I need to finish parsing and saving. This will also be used
for editing transfer control expresssions.
Removed the group display from the status output, I didn't really
like that format, and vicfg can be used to see as well as edit rempository
group membership.
|
| |
|
|
|
|
|
| |
--copies=group:number can now be used to match files that are present in a
specified number of repositories in a group.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
monthly incremental fsck runs in cron jobs.
|
|
|
|
| |
specified amount of time.
|
| |
|
|
|
|
| |
Not yet used..
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The default backend used when adding files to the annex is changed from
SHA256 to SHA256E, to simplify interoperability with OSX, media players,
and various programs that needlessly look at symlink targets.
To get old behavior, add a .gitattributes containing: * annex.backend=SHA256
|
|
|
|
|
|
|
| |
Used by the assistant, rather than copy, this is faster because it avoids
using git ls-files, avoids checking the location log redundantly, and
runs in oneshot mode, avoiding making a commit to the git-annex branch
for every file transferred.
|
|\ |
|
| |
| |
| |
| | |
automatically be generated, like "joey@gnu:~/foo"
|
| |
| |
| |
| |
| |
| |
| |
| | |
git annex assistant --autostart will start separate daemons in each
listed autostart repo
running the webapp outside any git-annex repo will open it on the
first listed autostart repo
|
| |
| |
| |
| | |
Remove --foreground and --stop options from it.
|
| | |
|
|\| |
|
| |
| |
| |
| | |
untested, but it compiles :)
|
|/
|
|
| |
like watch, but more magic
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
adds them
Use case for this was developed somewhere on the Transiberian Railroad.
|
|
|
|
| |
content into the git repository.
|
|
|
|
|
| |
Sort of by popular demand, but the last straw for not using seq
was that it can run into command line length limits.
|
|
|
|
|
|
| |
Allow custom headers to be sent with all HTTP requests.
(Requested by the Internet Archive)
|
|
|
|
|
|
|
|
|
|
| |
getConfig got a remote-specific config, and this confusing name caused it
to be used a couple of places that only were interested in global configs.
Rename to getRemoteConfig and make getConfig only get global configs.
There are no behavior changes here, but remote.<name>.annex-web-options
never actually worked (and per-remote web options is a very unlikely to be
useful case so I didn't make it work), so fix the documentation for it.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Add tuning, docs, etc.
Not sure if status is the right place to remote size.. perhaps unused
should report the size and also warn if it sees more keys than the bloom
filter allows?
|
|
|
|
|
|
| |
Locking is used, so that, if there are multiple git-annex processes
using a remote concurrently, the stop hook is only run by the last
process that uses it.
|
|
|
|
| |
than the old "." (which still works too).
|
|
|
|
| |
version of ssh and default annex.sshcaching accordingly.
|
|
|
|
|
|
| |
To avoid commits of data to the git-annex branch after each command
is run, set annex.alwayscommit=false. Its data will then be committed
less frequently, when a merge or sync is done.
|
| |
|
|
|
|
| |
files en masse.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
useful when adding hundreds of thousands of files on a system with plenty
of memory.
git add gets quite slow in such a large repository, so if the system has
more than the ~32 mb of memory the queue can use by default, it's a useful
optimisation to increase the queue size, in order to decrease the number
of times git add is run.
|
|
|
|
|
|
|
| |
Can be used to specify what file the url is added to. This can be used to
override the default filename that is used when adding an url, which is
based on the url. Or, when the file already exists, the url is recorded as
another location of the file.
|
| |
|
|
|
|
|
|
|
| |
Avoids expensive file transfers, at the expense of checking file size
and/or contents.
Required some reworking of the remote code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fscking a remote is now supported. It's done by retrieving
the contents of the specified files from the remote, and checking them,
so can be an expensive operation.
(Several optimisations are possible, to speed it up, of course.. This is
the slow and stupid remote fsck to start with.)
Still, if the remote is a special remote, or a git repository that you
cannot run fsck in locally, it's nice to have the ability to fsck it.
If you have any directory special remotes, now would be a good time to
fsck them, in case you were hit by the data loss bug fixed in the
previous release!
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the trust level of a remote.
This overrides the trust.log, and is overridden by the command-line trust
parameters.
It would have been nicer to have Logs.Trust.trustMap just look up the
configuration for all remotes, but a dependency loop prevented that
(Remotes depends on Logs.Trust in several ways). So instead, look up
the configuration when building remotes, storing it in the same forcetrust
field used for the command-line trust parameters.
|
|
|
|
|
| |
As part of this, I fixed up how log was getting the descriptions of
remotes.
|
| |
|