| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
repository they were added to and removed from.
This needs to run git log on the location log files to get at all past
versions of the file, which tends to be a bit slow.
It would be possible to make a version optimised for showing the location
logs for every key. That would only need to run git log once, so would be
faster, but it would need to process an enormous amount of data, so
would not speed up the individual file case.
In the future it would be nice to support log --format. log --json also
doesn't work right yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dotfiles, and files inside dotdirs are not added by "git annex add" unless
the dotfile or directory is explicitly listed. So "git annex add ." will
add all untracked files in the current directory except for those in
dotdirs.
One reason for this is that it will make git-annex more usable with vcsh,
where you don't want "vcsh big annex add" to check in all the dotfiles
that are already versioned in other repositories.
(If you're using vcsh for repos that contain non-dotfiles, this won't help,
and you'll need to .gitignore such things, but this will cover the common
case.)
A more general reason why this seems like a good idea is the same reason ls
ignores dotfiles, just the unix convention that they are cruft that is kept
out of the way most of the time.
All the other git-annex commands still do deal with any dotfiles that do
get into the annex. This seemed right because if I've gone to the trouble
to add a dotfile, I will want "git annex get ." to get it along with
everything else.
|
| |
|
| |
|
|
|
|
| |
to provide parameters to whichever of wget or curl git-annex uses (depends on which is available, but most of their important options suitable for use here are the same).
|
|
|
|
| |
syncs those, in addition to any specified at the command line.
|
| |
|
| |
|
|\ |
|
| | |
|
|/ |
|
| |
|
|
|
|
| |
Makes it easy to find files with duplicate contents, anyway.. :)
|
| |
|
| |
|
|
|
|
| |
is output by git annex find.
|
| |
|
|
|
|
| |
Generally useful, and allows the test suite to test it.
|
|
|
|
| |
by running git commit, pull, and push for you.
|
| |
|
|
|
|
| |
want git-annex to mention it again.
|
| |
|
|
|
|
| |
content is stored using a specified key-value backend.
|
|
|
|
|
|
|
|
|
|
|
| |
It would be nice if command-specific options were supported. The first
difficulty is that which command is being called is not known until after
getopt; but that could be worked around by finding the first non-dashed
parameter. Storing the settings without putting them in the annex monad is
the next difficulty; it could perhaps be handled by making the seek stage
pass applicable settings into the start stage (and from there on to perform
as needed). But that still leaves a problem, what data type to use to
represent the options between getopt and seek?
|
| |
|
|
|
|
|
|
| |
* status: Fix --json mode (only the repository lists are currently
displayed)
* status: --fast is back
|
| |
|
|
|
|
| |
option is no longer used.
|
|
|
|
| |
useful interface.
|
|
|
|
|
|
|
|
| |
kilobytes"
This reverts commit aeb4e285eb2b3b880ab6b91c5b1f7fa29d7182cb.
bup's --bwlimit does take a unit, unlike rsync's.
|
| |
|
| |
|
| |
|