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

followup

accidental dup

This reverts commit ece9429f4441345d6568ba1284054068d1c52ec1

much flailing

Added a comment

initial bug report on parallel get of the same key

comment

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

make --json-error-messages capture url download errors

Convert Utility.Url to return Either String so the error message can be
displated in the annex monad and so captured.

(When curl is used, its errors are still not caught.)

Added a comment: Another use case -- http_proxy

remove one more warningIO

Had to generalize Git.Queue so it can run an Annex action, yipes.

Only remaining warningIO are in the legacy chunk code.

use fromRepo

remove some unncessary uses of warningIO

warningIO is not concurrent output safe, and it doesn't go to
--json-error-messages

There are a few more that would be too hard to remove, and there are also
several dozen direct prints to stderr still.

refactor

Better to not have a single function module, and better to have a more
specific type than Bool.

This commit was sponsored by Jack Hill on Patreon

Added annex.allowsign option.

This commit was sponsored by Ilya Shlyakhter on Patreon.

mention special remotes

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

some improvements to docs

typo

fix language

typo

added todo about documenting sqlite database schemas

Added a comment: Re: Symlinks for not-present unlocked files in v8

Added a comment: Symlinks for not-present unlocked files in v8?

Added a comment: limiting clean/smudge filter to unlocked files

Added a comment: RFC: how would it work for regular git remote + special remote

Added a comment: A warning in the docs about earlier v7 revisions would be nice

removed

Added a comment: Consider deprecation warnings in the web app

Added a comment: Consider deprecation warnings in the web app

devblog

update status of sqlite branch

remove UNRELEASED marker

add news item for git-annex 7.20191106

prep release

Added a comment: Thanks!

update

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

update to document current state of sqlite branch

init: fix data loss bug

Fix bug that lost modifications to unlocked files when init is re-ran in an
already initialized repo.

In retrospect needing scanUnlockedFiles False in the direct mode upgrade
path was a good hint that it was unsafe when used with True.

However, this bug did not affect upgrade from v5. In such an upgrade, an
unlocked file that is modified is left as-is. The only place
scanUnlockedFiles True did overwrite modified unlocked files is during an
git-annex init of a repo that was already initialized by git-annex.

(I also tried a scenario where the repo had not been initialized by
git-annex yet, but was cloned from a v7 repo with an unlocked file, and the
pointer file replaced with some other content, and the data loss did not
occur in that situation.)

Since the fixed scanUnlockedFiles avoids overwriting non-pointer files,
it should be safe to run in any situation, so there's no need any longer
for the parameter.

fix typo

added <details> to fold done/fixed things

Added a comment

Added a comment: comment 5

Added a comment: Ssh config

added todo re: git-annex-sync handling of linked worktrees

Added a comment: the issue persists

Added a comment: Yggdrasill

Added a comment: annexing previously non-annexed files, and compatibility with v5

Added a comment: not annexing files already stored in git

more notes on communicating breaking changes

Added a comment: plz don't annex already committed files

added meta tags

initial report on an error message from addurl

Added a comment

Added a comment

benchmark: Add --databases to benchmark sqlite databases

Rescued from commit 11d6e2e260d70ba99e35464c19c2b2772ce9efaa which removed
db benchmarks in favor of benchmarking arbitrary git-annex commands. Which
is nice and general, but microbenchmarks are useful too.

Added a comment

Added a comment: ACLs keep fighting back

removed

Added a comment: What is a recent enough version?

Added a comment: re: setkey

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

devblog

Added a comment: Maybe this is the problem...

Added a comment: Should there have been a combine step?

Added a comment: Can you give more details?

Added a comment: Oh yeah, use verbose flag too.

Added a comment: A possible solution

Added a comment: Thank you

add news item for git-annex 7.20191024

releasing package git-annex version 7.20191024

Added a comment

Added a comment: Thank you

added todo "warn of breaking changes same way git does"

Added a comment: Triggering which stage and when?

prep release

make git add only annex when configured by annex.largefiles

documentation for making git add only annex when configured by annex.largefiles

Code change should be trvial, but not yet implemented. This
significantly complicated the task of documenting how git-annex works.

I'm not sure how useful the annex.gitaddtoannex confguration is after
this change; seems that if a user has an annex.largefiles they will want
it applied consistently. But the last thing I want to hear is more
complaining from users about git add doing something they don't want it
to.

There's a pretty high risk users who got used to the git add behavior
and don't have annex.largefiles configured will miss the NEWS and
complain bitterly about their suddenly bloated repositories. Oh well.

Removed outdated comments about the old behavior to avoid confusion.
I don't know if I've found all the places that griping spread to.

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

fix sql syntax

display sqlite error message when it crashes

avoid warning over name

Added a comment: Friendly bump to keep on the radar

Added a comment

Added a comment: right! forgot about log -S

update from comments

clarify

devblog

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

annex.gitaddtoannex configuration

Added annex.gitaddtoannex configuration. Setting it to false prevents
git add from usually adding files to the annex.
(Unless the file was annexed before, or a renamed annexed file is detected.)

Currently left at true; some users are encouraging it be set to false.