| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
| |
This option avoids gpg key distribution, at the expense of flexability, and
with the requirement that all clones of the git repository be equally
trusted.
|
| |
|
|
|
|
| |
Allow custom headers to be sent with all HTTP requests.
(Requested by the Internet Archive)
|
| | |
|
| |
|
|
| |
void :: Functor f => f a -> f () -- ah, of course that's useful :)
|
| |
|
|
| |
Lock files, directories, etc.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
legal git refs.
Continue using the key name as bup ref name, to preserve backwards
compatability, unless it is an illegal git ref. In that case, use a sha256
of the key name instead.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Nothing at all on hackage is using <&&> or <||>.
(Also, <&&> should short-circuit on failure.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
openSUSE patches rsync with a patch adding SIP protocol support.
https://gist.github.com/2026167
With this patch, running rsync with no hostname parameter is apparently
supposed to list SIP hosts on the network. Practically, it does nothing
and exits 0.
git-annex uses rsync in a very special way to allow git-annex-shell to be
run on the remote host, and so did not need to specify a hostname, or a
file to transfer as a rsync parameter. So it sent ":", a degenerate case of
"host:file".
But the patch cannot differentiate ":" with no host parameter
(a bug in the SIP patch surely).
Results were that getting files failed, as rsync seemed to succeed, but the
requested file failed to arrive. Also I think that sending files will
make git-annex think a file has been transferred to the remote when
really rsync does nothing.
The workaround for this buggy rsync patch is to use "dummy:" as the
hostname.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Avoids opening every chunk at once, instead streaming them in.
Not done for encrypted file retrieval yet.
|
| |
|
|
|
| |
Allows showing progress bar for this last case of the directory special
remote.
|
| |
|
|
|
|
| |
That was actually really easy. But, when getting a file from an encrypted
directory special remote, no meter can be shown, because the total file
size is not known.
|
| |
|
|
|
|
|
| |
So far I've only written progress bars for sending files, not yet
receiving.
No longer uses external cp at all. ByteString IO is fast enough.
|
| | |
|
| |
|
|
|
|
| |
Avoiding writing files larger than a specified size is useful on certian
things. For example, box.com has a file size limit of 100 mb. Could also
be useful on really crappy removable media.
|
| |
|
|
|
|
|
|
| |
Added Annex.cleanup, which is a general purpose interface for adding
actions to run at the end.
Remotes with the old git-annex-shell will commit every time, and have no
commit command, so hide stderr when running the commit command.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now gitattributes are looked up, efficiently, in only the places that
really need them, using the same approach used for cat-file.
The old CheckAttr code seemed very fragile, in the way it streamed files
through git check-attr.
I actually found that cad8824852aa0623dc41eac02a9e2bae47d88ec4
was still deadlocking with ghc 7.4, at the end of adding a lot of files.
This should fix that problem, and avoid future ones.
The best part is that this removes withAttrFilesInGit and withNumCopies,
which were complicated Seek methods, as well as simplfying the types
for several other Seek methods that had a Backend tupled in.
|
| |
|
|
|
|
|
|
| |
available, matches the size of the key.
If there's no Content-Length, or the key has no size, this check is not
done, but it should happen most of the time, and protect against web
content that has changed.
|
| | |
|
| |
|
|
| |
Wow, triple monadic lift!
|
| |
|
|
|
|
| |
ghc 7.4 comaplains about use of System.IO.Error to catch exceptions.
Ok, use Control.Exception, with variants specialized to only catch IO
exceptions.
|
| |
|
|
|
|
| |
Dropping a key from a local remote ran git-annex-shell unnecessarily.
Now git-annex-shell is never used when acting on a local remote.
|
| |
|
|
|
|
|
|
|
| |
Done by adding a oneshot mode, in which location log changes are written to
the journal, but not committed. Taking advantage of git-annex's existing
ability to recover in this situation.
This is used by git-annex-shell and other places where changes are made to
a remote's location log.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 6da40100c99a097401fb130b63edc05b18f61249.
On closer examinaton, this change is wrong. The bup special remote
can be configured with "buprepo=", which makes it use the default
~/.bup repo. This change makes it use a different temp dir each time,
which I'm sure would not be appreciated by anyone with that
configuration.
Bup insisting in creating ~/.bup even when using a different repo
does seem like a bug in *something*, but I'm leaning toward the bug
being in bup itself.
|
| | |
|
| |
|
|
|
|
|
| |
This drops the >>! and >>? with the nice low fixity. IfElse does have
undocumented >>=>>! and >>=>>? operators, but I deem that too fishy.
Anyway, using whenM and unlessM is easier; I sometimes mixed the operators
up.
|
| |
|
|
| |
So the user can override them.
|
| |
|
|
|
|
|
|
|
|
|
| |
Ssh connection caching is now enabled automatically by git-annex. Only one
ssh connection is made to each host per git-annex run, which can speed some
things up a lot, as well as avoiding repeated password prompts. Concurrent
git-annex processes also share ssh connections. Cached ssh connections are
shut down when git-annex exits.
Note: The rsync special remote does not yet participate in the ssh
connection caching.
|
| |
|
|
|
|
|
| |
Avoids expensive file transfers, at the expense of checking file size
and/or contents.
Required some reworking of the remote code.
|
| |
|
|
|
|
|
|
|
|
| |
For a local git remote, can symlink the file.
For a git remote using rsync, can preseed any local content.
There are a few reasons to use fsck --from on a normal git remote.
One is if it's using gitosis or similar, and you don't have shell access
to run git annex locally. Another reason could be if you just want to
fsck certian files of a bare remote.
|
| |
|
|
| |
No need to copy anything, just symlink to the file.
|
| | |
|
| |
|
|
|
| |
When a file is present locally, the remote's version can be rsynced to
a copy of it, which will avoid wasting a lot of bandwidth.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When moving a file to the remote failed, and partially transferred content
was left behind in the directory, re-running the same move would think it
succeeded and delete the local copy.
I reproduced data loss when moving files to a partition that was almost
full. Interrupting a transfer could have similar results.
Easily fixed by using a temp file which is then moved atomically into place
once the transfer completes.
I've audited other calls to copyFileExternal, and other special remote
file transfer code; everything else seems to use temp files correctly
(rsync, git), or otherwise use atomic transfers (bup, S3).
|
| | |
|
| |
|
|
| |
A PITA but worth it to clean up the trust configuration code.
|
| |
|
|
|
| |
Let's keep that in a no-s3 branch, which can be merged into eg,
debian-stable.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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).
|
| |
|
|
|
|
|
| |
With --fast, unavailable local remotes are filtered out of the fast set.
This way, if there are local remotes, --fast always acts only on them,
and if none are mounted, acts on nothing. This consistency is better
than --fast acting on different remotes depending on what's mounted.
|
Joey Hess
Lauri Alanko