comment

Added a comment

Added a comment

Updated patch

Added a comment

Fix using lookupkey inside a subdirectory

Caused by dirContains ".." "foo" being incorrectly False.

Also added a test of dirContains, which includes all the previous bug fixes
I could find and some obvious cases.

Reversion in version 8.20211011

Sponsored-by: Brett Eisenberg on Patreon

comment

review

when private journal file exists, still read from git-annex branch

Fix bug that caused stale git-annex branch information to read when
annex.private or remote.name.annex-private is set.

The private journal file should not prevent reading more current
information from the git-annex branch, but used to.

Note that, overBranchFileContents has to do additional work now, when
there's a private journal file, it reads from the branch redundantly
and more slowly.

Sponsored-by: Jack Hill on Patreon

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

Added a comment

Added a comment

Added a comment

still think we should highlight this as new info

Added a comment

Moved WSL1 guide to a tips page

Added a comment

Added a comment

remove obsolete libgcc1

last seen in debian oldstable

Added a comment

Added a comment

Added a comment

comment

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

fix build failure on windows

Utility.QuickCheck also has an instance Arbitrary FileID.
It seems that this problem used to be ignored by ghc but now it notices
it.

Added a comment: Same problem with git-annex 8.20210223

comment

comment

comment

update

oops, I misread, still happens for adjusted branches

linked bugs

changelog

A user tested 0f38ad9a69f07f6c6dfb164ad87ecfd56036496f on WSL, and it
seems to have fixed the problem.

comment

update per other comment

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

comment

avoid using a second db connection for writes

This is a potentially breaking change in a very delicate area. However,
examining the code path for writes, I don't see any benefit to opening a
second db connection for them. If the write throws an exception,
commitDb will retry it with a new db connection.

A potential benefit to not opening a second db connection, beyond using
less resources, is it just might avoid problems in WSL with sqlite that
I have hypothesized are caused by multiple db connections.

Commit 5f9eff3f32e0101ee673c3dde221f0f27f32e3c8 explains why it needs to
shut down the db connection to force the database to be updated on disk:
When closeDb does not get called, garbage collection of DbHandle may not
give the workterThread time to cleanly shut down before git-annex exits,
resulting in a recently written change not reaching disk.

eliminate single/multi writer distinction

After commit f4bdecc4ecce8bcbb2d8ccbb524ba1f3f76565ba, there is no
longer any distinction between SingleWriter and MultiWriter's handling
of read after write.

Databases that were SingleWriter still have lock files that are used to
prevent multiple writers.

This does make writing to such databases a bit more expensive,
because the MultiWriter code path that is now used opens a second db
connection in order to write to them.

improve with continuation

no behavior change

Added a comment

Added a comment: Still seeing the issue.

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

improve sqlite MultiWriter handling of read after write

This removes a messy caveat that was easy to forget and caused at least one
bug. The price paid is that, after a write to a MultiWriter db, it has to
close the db connection that it had been using to read, and open a new
connection. So it might be a little bit slower. But, writes are usually
batched together, so there's often only a single write, and so there should
not be much of a slowdown. Notice that SingleWriter already closed the db
connection after a write, so paid the same overhead.

This is the second try at fixing a bug: git-annex get when run as the first
git-annex command in a new repo did not populate all unlocked files.
(Reversion in version 8.20210621)

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

Added a comment

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

reopen

close keys db to possibly work around WSL1 issue

comment

remove xmpp mention

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

comment

Added a comment

Added a comment

update to lts-18.13

ghc 8.10

avoid warning when built with unix-compat 0.5.3

It re-exports modificationTimeHiRes, and provides a windows version.

Might be worth using that windows version eventually, but I have not
tested it.

rename to avoid warning

a new version of persistent exports an "exists"

Added a comment

remove osx stack.yaml

The OSX autobuilder is now using github CI, and can use a current
version of ghc, rather than the old one.

Sponsored-by: Dartmouth College's Datalad project

pin aws to revision 0

revision 1 seems to have introduced a build failure

Sponsored-by: Dartmouth College's Datalad project

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

Added a comment

note about encryption/chunking

Added a comment: directory special remote

Added a comment

Added a comment

Added a comment

Note about case sensitivity dirs

Update WSL1 instructions

Added a comment: GitHub Actions

update

comment

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

comment

comment

Added a comment: Update

removed

Added a comment: Update

When retrival from a chunked remote fails, display the error that occurred when downloading the chunk

Rather than the error that occurred when trying to download the unchunked
content, which is less likely to actually be stored in the remote.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

followup

remove 3 comments that turned out to be about an unrelated problem which got its own bug report

avoid crashing tilde expansion on user who does not exist

git does not crash when there's a remote configured for a user who does
not exist, and this prevents git-annex from crashing too. Consider that
a user might exist on one system but not another, and the git repo be
moved between systems. So not crashing is desirable.

Note that git fetch seems to mishandle a remote path like ~foo/bar
when the user does not exist. While it does access ./~foo/bar,
and gets as far as running git-upload-pack on the path,
it then complains there is no such repo. So different parts of git seem
to be doing different things in that edge case. Anyway, git-annex does
not need to be bug-for-bug compatible with git.

Sponsored-by: Jack Hill on Patreon

close per comment

open todo

move gpg tmp home to system temp dir

test: Put gpg temp home directory in system temp directory, not filesystem
being tested.

Since I've found indications gpg can fail talking to the agent when the
socket ends up on eg, fat. And to hopefully fix this bug report I've
followed up on.

The main risk in using the system temp dir is that TMPDIR could be set to a
long directory path, which is too long to put a unix socket in. To
partially amelorate that risk, it uses either an absolute or a relative
path, whichever is shorter. (Hopefully gpg will not convert it to a longer
form of the path..)

If the user sets TMPDIR to something so long a path to it +
"S.gpg-agent" is too long, I suppose that's their issue to deal with.

Sponsored-by: Dartmouth College's Datalad project

remove support code for ancient git-annex-shell version

Wow, 5.20140405.. Yeah, definitely not supported any more, just landed
commits need 6.20180312.