| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
Avoids expensive file transfers, at the expense of checking file size
and/or contents.
Required some reworking of the remote code.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Left a few Prelude.head's in where it was checked not null and too hard to
remove, etc.
|
| | |
|
| |
|
|
|
| |
Constructors and configuration make sense in separate modules.
A separate Git.Types is needed to avoid cycles.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Supporting multiple directory hash types will allow converting to a
different one, without a flag day.
gitAnnexLocation now checks which of the possible locations have a file.
This means more statting of files. Several places currently use
gitAnnexLocation and immediately check if the returned file exists;
those need to be optimised.
|
| | |
|
| |
|
|
|
|
|
|
| |
git-annex-shell inannex now returns always 0, 1, or 100 (the last when
it's unclear if content is currently in the index due to it currently being
moved or dropped).
(Actual locking code still not yet written.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Many functions took the repo as their first parameter. Changing it
consistently to be the last parameter allows doing some useful things with
currying, that reduce boilerplate.
In particular, g <- gitRepo is almost never needed now, instead
use inRepo to run an IO action in the repo, and fromRepo to get
a value from the repo.
This also provides more opportunities to use monadic and applicative
combinators.
|
| |
|
|
|
|
|
| |
Avoid ever using read to parse a non-haskell formatted input string.
show :: Key is arguably still show abuse, but displaying Keys as filenames
is just too useful to give up.
|
| |
|
|
| |
Should have done this a long time ago.
|
| | |
|
| | |
|
| |
|
|
| |
no code changes
|
| | |
|
| | |
|
| |
|
|
| |
no code changes
|
| |
|
|
|
|
|
|
| |
Only one place need to filter the list of remotes for ignored remotes:
keyPossibilities. Make the full list available to everything else.
This allows getting rid of the special case handing for --from and --to
to make ignored remotes not be ignored with those options.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
And add a simple dots-based progress display, currently only used in v2
upgrade.
|
| | |
|
| | |
|
| |
|
|
| |
It was always imported qualified as Git anyway
|
| | |
|
| |
|
|
|
|
|
| |
These are defined in ifelse, but it's not currently available and I don't
want to pull in a library for 6 lines of code anyhow.
Also, ifelse sets the fixity to 1, which does not allow >>? error $ ...
|
| |
|
|
|
| |
Just more golfing.. I am pretty sure something in a library somewhere can
do this, but I have been unable to find it.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was a most surprising leak. It occurred in the process that is forked
off to feed data to gpg. That process was passed a lazy ByteString of
input, and ghc seemed to not GC the ByteString as it was lazily read
and consumed, so memory slowly leaked as the file was read and passed
through gpg to bup.
To fix it, I simply changed the feeder to take an IO action that returns
the lazy bytestring, and fed the result directly to hPut.
AFAICS, this should change nothing WRT buffering. But somehow it makes
ghc's GC do the right thing. Probably I triggered some weakness in ghc's
GC (version 6.12.1).
(Note that S3 still has this leak, and others too. Fixing it will involve
another dance with the type system.)
Update: One theory I have is that this has something to do with
the forking of the feeder process. Perhaps, when the ByteString
is produced before the fork, ghc decides it need to hold a pointer
to the start of it, for some reason -- maybe it doesn't realize that
it is only used in the forked process.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Forking a new process rather than relying on a thread to feed gpg.
The feeder thread was stalling, probably when the main thread got
to the point it was wait()ing on the gpg to exit.
|
| |
|
|
|
| |
Some kind of laziness issue that I don't want to debug right now,
and decryption is not implemented.
|
| |
|
|
|
| |
Encrypted remotes don't yet encrypt data, but git annex initremote can
be used to generate a cipher and add additional gpg keys that can use it.
|
| | |
|
| |
|
|
|
| |
I don't trust the location log, even for bup. Too many things could go
wrong.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Instead of remote=, use buprepo=
Anyone already using bup will need to re-run git annex initremote.
|
| | |
|
| |
|
|
| |
does have to run bup and reassemble files, after all
|
| | |
|
| | |
|
Joey Hess