| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
This reverts commit 699a90bdc195a67c5aa5fca34fcaa07fb2b530ae.
My windows build environment was broken; reverted to backup.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This used to work, but now hsc2hs is failing with a usage message.
Since I have not changed my windows build environment at all, it must be
some change due to a change in the cabal file. Perhaps too make flags are
causing it to hit a windows command line length limit?
Anyway, these hsc files did nothing on Windows, so can be omitted and not
built to work around yet another epic windows weirdness.
|
| |
|
|
| |
Experimentally, using the raw TopFilePath was right here.
|
| |
|
|
|
|
|
|
|
| |
This actually fixes a bug; if pre-commit was run in a subdir, it would pass
relative files when updating the associated file maps, and so the maps
wouldn't update.
I don't think this bug happened in practice, due to the way pre-commit is
called by the hook. It happened to chdir to the top of the work tree.
|
| | |
|
| |
|
|
|
| |
git-merge's creation of file~HEAD type files did not make this especially
nice to do.
|
| |
|
|
|
|
|
|
|
| |
annexed file, and the other side is a non-annexed file, or a directory.
Note that this case is only fully automatically resolved in direct mode.
In indirect mode, git merge moves the file to file~HEAD, and replaces it
with the directory, and leaves the file in unmerged state, and sync doesn't
yet change that.
|
| |
|
|
|
| |
Mostly because it gives me an excuse and a hook to document the schedule
expression format.
|
| |\ |
|
| | |
| |
| |
| | |
checked for status.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
addurl: Improve message when adding url with wrong size to existing file.
Before the message suggested the url didn't exist.
Fixed handling of URL keys that have no recorded size. Before, if the key
has no size, the url also had to not declare any size, which was unlikely
and wrong, or it was taken to not exist. This probably would mostly affect
keys that were added to the annex with addurl --relaxed.
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
| |
This reverts commit c0caa37187e9c062825dd6d5cb6be2dfa63bc7dd.
|
| |
|
|
|
|
| |
Thought was that this would be faster than a map, since a vector can be
updated more efficiently. It turns out to not seem to matter; runtime and
memory usage are basically identical.
|
| |
|
|
| |
Actually fixed 2 leaks, the tuple leak may have been older.
|
| | |
|
| |
|
|
| |
Use sanitizeFilePath rather than rolling our own sanitizer.
|
| | |
|
| | |
|
| |
|
|
|
| |
This was the least-bad alternative to get dedicated key gcrypt repos
working in the assistant.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
recvkey was told it was receiving a HMAC key from a direct mode repo,
and that confused it into rejecting the transfer, since it has no way to
verify a key using that backend, since there is no HMAC backend.
I considered making recvkey skip verification in the case of an unknown
backend. However, that could lead to bad results; a key can legitimately be
in the annex with a backend that the remote git-annex-shell doesn't know
about. Better to keep it rejecting if it cannot verify.
Instead, made the gcrypt special remote not set the direct mode flag when
sending (and receiving) files.
Also, added some recvkey messages when its checks fail, since otherwise
all that is shown is a confusing error message from rsync when the remote
git-annex-shell exits nonzero.
|
| |/
|
|
| |
Similar to how a similar problem with indirect was earlier fixed.
|
| |
|
|
|
|
|
|
|
| |
Overridable with --user-agent option.
Not yet done for S3 or WebDAV due to limitations of libraries used --
nether allows a user-agent header to be specified.
This commit sponsored by Michael Zehrer.
|
| |
|
|
|
|
|
|
| |
I forgot I had <$$> hidden away in Utility.Applicative.
It allows doing the same kind of currying as does >=*>
and I found using it made the code more readable for me.
(*>=> was not used)
|
| |
|
|
|
| |
Still need to detect when the user is trying to create a repo
that already exists, and jump to the enabling code.
|
| |
|
|
|
|
|
| |
adding content that gets deduplicated.
Note that this turned out to remove a syscall, not add any expense.
Otherwise, I would not have done it.
|
| |
|
|
| |
user running the conversion.
|
| |
|
|
| |
test suite still passes
|
| |
|
|
|
|
| |
* Note that the layout of gcrypt repositories has changed, and
if you created one you must manually upgrade it.
See http://git-annex.branchable.com/upgrades/gcrypt/
|
| |
|
|
|
| |
This has the dual benefits of making Remote.Git shorter, and letting
Remote.GCrypt use these utilities.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Done using a mode witness, which ensures it's fixed everywhere.
Fixing catFileKey was a bear, because git cat-file does not provide a
nice way to query for the mode of a file and there is no other efficient
way to do it. Oh, for libgit2..
Note that I am looking at tree objects from HEAD, rather than the index.
Because I cat-file cannot show a tree object for the index.
So this fix is technically incomplete. The only cases where it matters
are:
1. A new large file has been directly staged in git, but not committed.
2. A file that was committed to HEAD as a symlink has been staged
directly in the index.
This could be fixed a lot better using libgit2.
|
| |
|
|
| |
from git, which can be so large it runs out of memory.
|
| | |
|
| | |
|
| |
|
|
| |
Looking up the location log for every key is not the fastest operation..
|
| |
|
|
| |
numcopies levels.
|
| | |
|
| | |
|
| |
|
|
| |
represented as standin symlinks on crippled filesystems.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
files. (Thanks, anarcat for display code and mastensg for inspiration.)
Note that it would be possible to extend the display to show all
repositories. But there can be a lot of repositories that are not set up as
remotes, and it would significantly clutter the display to show them all.
Since we're not showing all repositories, it's not worth trying to show
numcopies count either.
I decided to embrace these limitations and call the command remotes.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a git-remote-gcrypt encrypted special remote. Only sending files
in to the remote works, and only for local repositories.
Most of the work so far has involved making initremote work. A particular
problem is that remote setup in this case needs to generate its own uuid,
derivied from the gcrypt-id. That required some larger changes in the code
to support.
For ssh remotes, this will probably just reuse Remote.Rsync's code, so
should be easy enough. And for downloading from a web remote, I will need
to factor out the part of Remote.Git that does that.
One particular thing that will need work is supporting hot-swapping a local
gcrypt remote. I think it needs to store the gcrypt-id in the git config of the
local remote, so that it can check it every time, and compare with the
cached annex-uuid for the remote. If there is a mismatch, it can change
both the cached annex-uuid and the gcrypt-id. That should work, and I laid
some groundwork for it by already reading the remote's config when it's
local. (Also needed for other reasons.)
This commit was sponsored by Daniel Callahan.
|
Joey Hess
Antoine Beaupré