| Commit message (Collapse) | Author | Age |
| |
|
| |
|
|
|
|
|
|
|
|
| |
The crash turned out to be caused by the sqlite database being deleted out
from under sqlite before it was done with it. Since multiple git_annex
calls are done in the same process while running the test suite, the
DbHandle could linger until GCed, and the test repo, and thus sqlite
database be deleted before the workerThread was done.
|
|
|
|
| |
ugly escaping, as the unicode method doesn't work on non-unicode supporting systems.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
(but not git rmed). git still has the add staged in this case, so the content should not be unused and was wrongly treated as such.
So, we need to look at both the file on disk to see if it's a annex link,
and the file in the index too. lookupFile doesn't look in the index if the file
is not present on disk.
|
|
|
|
| |
fix is not relevant for unlocked files
|
|
|
|
|
|
|
| |
have to change the content of unlocked file before committing
otherwise git commit will fail in v6 mode when the file was already
unlocked, because no changes have been made
|
|
|
|
| |
file is locked here, so use right test.
|
|
|
|
|
|
|
|
| |
In v5, that was not possible, but it is in v6, and so the test was failing.
Investigating, it turns out that locking was copying the pointer file
content to the annex object despite the content not being present. So,
add a check to prevent that.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Many failures.
|
| |
|
|
|
|
|
| |
Set annex.largefiles when adding the conflicting non-annexed file,
otherwise it would be added as an annexed file.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WorkTree.lookupFile was finding a key for a file that's deleted from the
work tree, which is different than the v5 behavior (though perhaps the same
as the direct mode behavior). Fix by checking that the work tree file exists
before catting its key.
Hopefully this won't slow down much, probably the catKey is much more expensive.
I can't see any way to optimise this, except perhaps to make Command.Unused
check if work tree files exist before/after calling lookupFile. But,
it seems better to make lookupFile really only find keys for worktree files;
that's what it's intended to do.
|
|
|
|
| |
The ingitfile was having git run it through the clean filter in some cases.
|
|
|
|
| |
Need to run that check inside a annex repo.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
(Only --from for now, should add --to sometime but I'm on low sleep so this
is the mininal test to catch the reversion just fixed, bad me for doing it
backwards and incompletely.)
|
|
|
|
|
|
| |
When gpg.program is configured, it's used to get the command to run for
gpg. Useful on systems that have only a gpg2 command or want to use it
instead of the gpg command.
|
| |
|
|
|
|
|
| |
This makes bash completion work for git-annex test, and is
generally cleaner.
|
| |
|
| |
|
|
|
|
| |
Debian stable has 0.10.0.
|
| |
|
|
|
|
| |
Added during a dev session in Jan and kept accidentially.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes a bit of complexity, and should make things faster
(avoids tokenizing Params string), and probably involve less garbage
collection.
In a few places, it was useful to use Params to avoid needing a list,
but that is easily avoided.
Problems noticed while doing this conversion:
* Some uses of Params "oneword" which was entirely unnecessary
overhead.
* A few places that built up a list of parameters with ++
and then used Params to split it!
Test suite passes.
|
|
|
|
|
| |
The explict import Prelude after import Control.Applicative is a trick
to avoid a warning.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
special remote. This was a reversion caused by the relative path changes in 5.20150113.
The directory special remote was not affected in its normal configuration,
since annex-directory is an absolute path normally. But it could fail
when a relative path was used.
The git remote was affected even when an absolute path to it was used in
.git/config, since git-annex now converts all such paths to relative.
|
|
|
|
| |
Seems list order matters, I don't know why, but have reported it on #tasty
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
strings that contained both unicode characters and a space (or '!') character.
The fix is to stop using w82s, which does not properly reconstitute unicode
strings. Instrad, use utf8 bytestring to get the [Word8] to base64. This
passes unicode through perfectly, including any invalid filesystem encoded
characters.
Note that toB64 / fromB64 are also used for creds and cipher
embedding. It would be unfortunate if this change broke those uses.
For cipher embedding, note that ciphers can contain arbitrary bytes (should
really be using ByteString.Char8 there). Testing indicated it's not safe to
use the new fromB64 there; I think that characters were incorrectly
combined.
For credpair embedding, the username or password could contain unicode.
Before, that unicode would fail to round-trip through the b64.
So, I guess this is not going to break any embedded creds that worked
before.
This bug may have affected some creds before, and if so,
this change will not fix old ones, but should fix new ones at least.
|
| |
|
| |
|