ported almost all remotes, until my brain melted

external is not started yet, and S3 is part way through and not
compiling yet

convert configParser to Annex action and add passthrough option

Needed so Remote.External can query the external program for its
configs. When the external program does not support the query,
the passthrough option will make all input fields be available.

fix wrong type

Use of Typeable means the type checker can't catch this kind of mistake,
the error is deferred to runtime.

testremote now passes on a directory special remote

separate RemoteConfig parsing basically working

Many special remotes are not updated yet and are commented out.

wip separate RemoteConfig parsing

Remote now contains a ParsedRemoteConfig. The parsing happens when the
Remote is constructed, rather than when individual configs are used.

This is more efficient, and it lets initremote/enableremote
reject configs that have unknown fields or unparsable values.

It also allows for improved type safety, as shown in
Remote.Helper.Encryptable where things that used to match on string
configs now match on data types.

This is a work in progress, it does not build yet.

The main risk in this conversion is forgetting to add a field to
RemoteConfigParser. That will prevent using that field with
initremote/enableremote, and will prevent remotes that already are set
up from seeing that configuration. So will need to check carefully that
every field that getRemoteConfigValue is called on has been added to
RemoteConfigParser.

(One such case I need to remember is that credPairRemoteField needs to be
included in the RemoteConfigParser.)

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

be stricter about rejecting invalid configurations for remotes

This is a first step toward that goal, using the ProposedAccepted type
in RemoteConfig lets initremote/enableremote reject bad parameters that
were passed in a remote's configuration, while avoiding enableremote
rejecting bad parameters that have already been stored in remote.log

This does not eliminate every place where a remote config is parsed and a
default value is used if the parse false. But, I did fix several
things that expected foo=yes/no and so confusingly accepted foo=true but
treated it like foo=no. There are still some fields that are parsed with
yesNo but not not checked when initializing a remote, and there are other
fields that are parsed in other ways and not checked when initializing a
remote.

This also lays groundwork for rejecting unknown/typoed config keys.

Added a comment: using hardlinks

2020

Added a comment: Summary; Application: shared thumbnails

comment

notes on my recovery from a bad merge

comment

response

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

Added a comment: git-annex in docker on Windows

fix a transcription error - to disable a remote, we set ignore to true, not false!

Added a comment: WSL 1/2 experience

Added a comment

removed

Added a comment: hi

generalize docs so they will also work when git uses SHA256

response

response

Added a comment: prior research

plan

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

use --no-abbrev instead of --abbrev=40

This avoids hardcoding the sha size, so when git uses sha256, it will
output the full sha256 and not a truncation to 40 characters.

I reviewed git's history, and while there have been some
bugs with commands not supporting --no-abbrev (eg git diff --no-index
--no-abbrev was broken in git 2.1), none of the commands git-annex
uses will be impacted by those old bugs.

support sha256 git repos

Git will eventually switch to sha2 and there will not be one single
shaSize anymore, but two (40 and 64).

Changed all parsers for git plumbing output to support both sizes of
shas.

One potential problem this does not deal with is, if somewhere in
git-annex it reads two shas from different sources, and compares them
to see if they're the same sha, it would fail if they're sha1 and sha256
of the same value. I don't know if that will really be a concern.

Added a comment

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

comment

fix typo in close

comment

comment

Added a comment

close, redundant

comment and close

comments

reinject --known: Fix bug that prevented it from working in a bare repo.

ifAnnexed in a bare repo passes to git cat-file :./filename , which it
refuses to do since the repo is bare.

Note that, reinject somefile someannexedfile in a bare repo silently does
nothing, because someannexedfile is never actually an annexed worktree
file, because the repo is bare.

comment

comment

update

Removed some encoding issues that I think are no longer a problem.

comment

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

improve comment

comment

Added a comment: Would you accept a patch implementing an annex.autocommit gitattribute?

use conversion functions from filepath-bytestring (again)

This reverts commit 3a04af7927afaac9aa65e65157201c35304df964.

a new TODO for having windows build with MagicMime

simplfy unix-compat dep

devblog

comment

comments

fix comment location

avoid build warning on windows

update comments to point to conversion docs

want to avoid use of -c annex.largefiles..

fix windows build

comment

add --force-annex/--force-git

options make it easier to override annex.largefiles configuration
(and potentially safer as it avoids bugs like the smudge bug fixed
in the last release)

Deleted some old comments that were posted to the man page discussing such
options.

Updated docs that used -c annex.largefiles to use the options.

Note that addSmallOverridden was needed to avoid the clean filter running
on the file. It would be possible to make addFile also update the index
directly, rather than going via git add. However, it was not necessary,
and I want to avoid breaking on some edge case, particularly if the code in
addSmallOverridden has some oversight.

Also, when annex.addunlocked is set and annex.largefiles does not match a file,
git annex add --force-large works, but git status will then show the file
as added, with a unstaged modification. The unstaged modification adds the
file to git. This is identical behavior to using -c annex.largefiles=nothing
when annex.addunlocked is set. This does not prevent committing what was
intended to be added. I have not gotten to the bottom of why git thinks
the file is modified and runs it through the clean filter in this case.

windows build fix

windows build fix

windows build fix

windows build fix

force move

Move will fail if the file is already on website and was re-downloaded
to generate rpms with, so force makes sure it moves.

update for RawFilePath changes

Added a comment: named pipes and external remotes

add news item for git-annex 7.20191230

releasing package git-annex version 7.20191230

comment

fix quickcheck failure

prop_encode_decode_roundtrip failed on "\175" in C locale.

This may be a new problem after the switch to RawFilePath, but it
already had filtering for high chars, so changed to only test ascii
chars.

if hdiutil create never succeeds, fail the build

Build was succeeding despite the dmg never being created.

different way to avoid NUL in Arbitrary AssociatedFile

Test case has been intermittently failing, with an AssociatedFile that
somehow contains a NUL despite it being filtered out. My guess is
something to do with locales. This new approach should prevent any NUL
at all, although it does weigh the distribution a bit more toward
Nothing.

adjust filepath-bytestring deps

cabal needs to support the old one for debian currently, but stack can
require the newer one

Added a comment: Duplicate 'gcrypt-id' may be the issue?

Added a comment

temporary revert "use conversion functions from filepath-bytestring"

This reverts commit 75c40279c1600da157c2ba0981989da9eaf1c502.

Debian unstable is one version too old, so this can be de-reverted in a
bit.

add filepath-bytestring

add libghc-filepath-bytestring-dev build dep

Debian impressively packaged my new library before anyone even asked
them to, and before git-annex needed it.

close

fix a case where file tracked by git unexpectedly becomes annex pointer file

smudge: When annex.largefiles=anything, files that were already stored in
git, and have not been modified could sometimes be converted to being
stored in the annex. Changes in 7.20191024 made this more of a problem.
This case is now detected and prevented.

comment

update on variant

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

followup

implelented in v8

didn't mean to commit this incomplete workaround

though I suppose it's nice to have it in the history..

analysis

added  projects/datalad

Added a comment: Workaround

link from bug report to submodules to make the affecting bug visible there

Added a comment

add workaround