| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
| |
to avoid contending with the user's desktop login process.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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..
|
Joey Hess
Antoine Beaupré