I got the files to come back, but I don't want Android making these dumb delete-loads-of-newly-added-stuff commits

Merge branch 'master' of ssh://git-annex.branchable.com

info: Support being passed a treeish, and show info about the annexed files in it similar to how a directory is handled.

Added a comment

Added a comment

comment

Merge branch 'master' of ssh://git-annex.branchable.com

stack.yaml: Update to lts-7.0 (ghc 8)

A few of these extra-deps are setting versions to work around various
library dep issues with ghc 8.

remove redundant constraint

remove workaround for ghc 8.0; that is mostly sorted out upstream now

Improve gpg secret key list parser to deal with changes in gpg 2.1.15. Fixes key name display in webapp.

gpg 2.1.15 (or so) seems to have added some new fields to the --with-colons
--list-secret-keys output. These include "fpr" and "grp", and come before
the "uid" line. So, the parser was giving up before it saw the name. Fix by
continuing to look for the uid line until the next "sec" line.

This commit was sponsored by Ole-Morten,Duesund on Patreon.

comment

Merge branch 'master' of ssh://git-annex.branchable.com

comment

Added a comment: clarification

Added a comment

Added a comment

Added a comment: Any thoughts Joey?

fix markup

sign this so i follow its changes

two more ideas

Added a comment: Never mind

drop incremental json object display; clean up code

This gets rid of quite a lot of ugly hacks around json generation.

I doubt that any real-world json parsers can parse incomplete objects, so
while it's not as nice to need to wait for the complete object, especially
for commands like `git annex info` that take a while, it doesn't seem worth
the added complexity.

This also causes the order of fields within the json objects to be
reordered. Since any real json parser shouldn't care, the only possible
problem would be with ad-hoc parsers of the old json output.

Merge branch 'master' of ssh://git-annex.branchable.com

refactor

copy, move, mirror: Support --json and --json-progress.

done

make --json-progress work for url downloads

make --json-progress update meter when getting from git remote with rsync

better locking for json with -J

Avoid threads emitting json at the same time and scrambling, which was
still possible even with the buffering, just less likely.

Converted json IO actions to JSONChunk data too.

addurl, get: Added --json-progress option, which adds progress objects to the json output.

This doesn't work right when used with -J yet, and there is some really
ugly hand-crafting of part of the json output.

initial whining

Remove key:null from git-annex add --json output.

make maybeShowJSON also add to the buffer

buffer json output until done when in concurrent mode

disentangle concurrency and message type

This makes -Jn work with --json and --quiet, where before
setting -Jn disabled those options.

Concurrent json output is currently a mess though since threads output
chunks over top of one-another.

Added a comment

Added a comment

Added a comment: Similar issue on Debian machine

removed

Added a comment: Tried on another machine, same problem

Added a comment: output of git annex version

Added a comment

Added a comment: concurrent-output-1.7.7

Merge branch 'master' of ssh://git-annex.branchable.com

still update othermeter when not displaying progress at console

See no reason not to do this; the othermeter will be updating a transfer
info file or the like.

Rate limit console progress display updates to 10 per second. Was updating as frequently as changes were reported, up to hundreds of times per second, which used unncessary bandwidth when running git-annex over ssh etc.

comment

Added a comment: also CPU (on git and git-annex processes) doesn't go to 100%

comment

Merge branch 'master' of ssh://git-annex.branchable.com

update

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

designs

Added a comment

Added a comment: This seems relevant to the comment directly previous this one.

Added a comment: Build failure

avoid deprecation warning from parseUrl

add news item for git-annex 6.20160907

prep release

followup

close; notabug

remove cruft

Added a comment

Added a comment

you can create bugs with empty titles

devblog

squelch build warning on windows

typo

stop removing old builds again

avoid build warnings when building w/o concurrent-output

fix build with pre-AMP ghc

pin mwc-random to last known working version on windows

revert 3fac05bf5e8843402d93451fcf340e9d094cf53c

This broke the windows build, the android build, the debian stable build, ...

constrain cryptonite version to avoid windows build fail

https://github.com/haskell-crypto/cryptonite/issues/99

try using cabal constraint

perisstent-sqlite-2.2.1 fails to build on windows

remove old cabal install libraries to try to fix windows autobuilder

Merge branch 'master' of ssh://git-annex.branchable.com

get -J: Download different files from different remotes when the remotes have the same costs.

Only done in -J mode because only if there's concurrency can downloading
from two remotes be faster. Without concurrency, it's likely the case that
sequential downloads from the same remote are faster than switching back
and forth between two remotes.

There is some hairy MVar code here, but basically it just keeps
the activeremotes MVar full except when deciding which remote to assign
to a thread.

Also affects gets by sync --content -J

This commit was sponsored by Jochen Bartl.

use keyLocations not loggedLocations

Skip dead remotes.

Added a comment: current status?

Merge branch 'master' of ssh://git-annex.branchable.com

applied

one dep per line and add comments about workaround deps

git-annex.cabal: persistent ==2.2.4.1

Simplify Solver's task by requesting version 2.2.4.1 of the persistent
package instead of just providing the persistent < 2.5 constraint.

With only the persistent < 2.5 constraint, and with --flags=s3\ webapp
and --max-backjumps=10000, CI timed out after two hours with Solver
still trying to find a solution.

This is a follow-up to 18e458db, since there's been a regression in the
situation between 6.20160619 and 6.20160808, probably simply because
Hackage is a moving target.

copy --from --to