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

report bug

report difficulty encountered when using submodules

Added a comment: windows installer has not been updated to version 7.20191218

fix copy/paste mistake

file bug

Improve file ordering behavior when one parameter is "." and other parameters are other directories

eg, `git-annex get . ..` used to order the files strangly, because it
did not realize that when git ls-files output eg "foo", that should be
grouped with the first set of files and not the second set.

Fixed by making            dirContains "." "./foo" = True
which makes sense, because dirContains ".." "../foo" = True

comment

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

annex.addunlocked expressions

* annex.addunlocked can be set to an expression with the same format used by
  annex.largefiles, in case you want to default to unlocking some files but
  not others.
* annex.addunlocked can be configured by git-annex config.

Added a git-annex-matching-expression man page, broken out from
tips/largefiles.

A tricky consequence of this is that git-annex add --relaxed
honors annex.addunlocked, but an expression might want to know the size
or content of an url, which it's not going to download. I decided it was
better not to fail, and just dummy up some plausible data in that case.

Performance impact should be negligible. The global config is already
loaded for annex.largefiles. The expression only has to be parsed once,
and in the simple true/false case, it should not do any additional work
matching it.

Added a comment: oh hoh, there is mimeencoding now

elaborated on my previous (marked "done") bug report about mimetypes

improve docs of addunlocked re adjusted branches

git-annex-config --set/--unset: No longer change the local git config setting

e53070c1f quietly made it set the local git config too, but that was never
documented anywhere, and it had surprising results. If I set
annex.largefiles globally in a repo, I would expect to be able to change it
in another repo, and the original repo would get the change and use it,
rather than being stuck on the old value set there.

And, if I have a local annex.largefiles and set a different global default,
I'd be surprised to have my local setting overwritten.

annex.securehashesonly does need to be set locally, since it's a security
feature and the global is only a default until it gets set locally. So
special cased.

when annex.largefiles parse fails, say where the config came from

fix syntax of largefiles example

has always been wrong syntax!

git-annex config annex.largefiles

annex.largefiles can be configured by git-annex config, to more easily set
a default that will also be used by clones, without needing to shoehorn the
expression into the gitattributes file. The git config and gitattributes
override that.

Whenever something is added to git-annex config, we have to consider what
happens if a user puts a purposfully bad value in there. Or, if a new
git-annex adds some new value that an old git-annex can't parse.
In this case, a global annex.largefiles that can't be parsed currently
makes an error be thrown. That might not be ideal, but the gitattribute
behaves the same, and is almost equally repo-global.

Performance notes:

git-annex add and addurl construct a matcher once
and uses it for every file, so the added time penalty for reading the global
config log is minor. If the gitattributes annex.largefiles were deprecated,
git-annex add would get around 2% faster (excluding hashing), because
looking that up for each file is not fast. So this new way of setting
it is progress toward speeding up add.

git-annex smudge does need to load the log every time. As well as checking
the git attribute. Not ideal. Setting annex.gitaddtoannex=false avoids
both overheads.

fixed an oversight that had always prevented annex.resolvemerge from being honored, when it was configured by git-annex config

forgot to add it to the merge function

improve docs of gitaddtoannex

thought

comment

Merge branch 'bs'

typo

formatting

comment

comment

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

devblog

more RawFilePath

Remove dup definitions and just use the RawFilePath one. </> etc are
enough faster that it's probably faster than building a String directly,
although I have not benchmarked.

todo

keep filename ByteString

Minor optimisation, since it still has to be copied from lazy to strict,
but it will add up when doing a big merge.

wrap up

Merge branch 'master' into bs

and update changelog

added dep for custom-setup

stack build failed w/o this though cabal old-build succeeded.

Added a comment: named pipes as destination files

more build fix

build fixes

get any old rpms

to prevent makerepo from falling over on broken symlinks

only delete old rpms for arches that have a new rpm

fixed

remove old rpms

Don't want a mass of old versions of git-annex in rpm form cluttering up
my server.

Also, makerepo falls over when confronted with a dangling symlink.

fix build

add news item for git-annex 7.20191218

inprogress: Support --key

add back changelog entry

comment

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

Merge branch 'master' into bs

use conversion functions from filepath-bytestring

Behavior should be the same, but I'd hope to eventually get rid of
most of Utility.FileSystemEncoding and this is a first step.

fix ByteString conversion on windows

the encode' and decode' functions on Windows should not apply the
filesystem encoding, which does not work there. Instead, convert to and
from UTF-8.

Also, avoid exporting encodeW8 and decodeW8. Both use the filesystem
encoding, so won't work as expected on windows.

update

fix fileJournal

My ByteString rewrite oversimplified it, resulting in any _ in a journal
file turning into a / in the git-annex branch, which was often the wrong
filename, or sometimes (//) an invalid filename that git
refused to add.

Added a comment: repodata is outdated

add todo

ask for --key on git-annex-inprogress

Added a comment: Would be useful

bug report

Added a comment

more info for debugging

add test case for bug

bug in this branch

match also / path separator on windows

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

devblog

use filepath-bytestring for annex object manipulations

git-annex find is now RawFilePath end to end, no string conversions.
So is git-annex get when it does not need to get anything.
So this is a major milestone on optimisation.

Benchmarks indicate around 30% speedup in both commands.

Probably many other performance improvements. All or nearly all places
where a file is statted use RawFilePath now.

Added a comment: annex-verify