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

fix inverted logic in recent commit

removed

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

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

sync --no-content import from directory special remote

sync: When run without --content, import without copying from
importtree=yes directory special remotes. (Other special remotes may
support this later as well.)

This commit was sponsored by Svenne Krap on Patreon.

consistently use importKey when available

This avoids import with --no-content and with --content potentially
generating two different trees, leading to a merge conflict when run in
two different clones of a repo. And it's necessary groundwork to make
git-annex sync --no-content import from special remotes that support
importKey.

Only the directory special remote currently supports importKey, and it
generates the same key as git-annex usually does, so there is no
behavior change for it.

Future special remotes will need to take care when adding importKey,
if it generates different keys. Added some warnings about that to
comments.

This commit was sponsored by Noam Kremen on Patreon.

import --no-content: Check annex.largefiles

Import small files into git, the same as is done when importing with content.
Which means, for small files, --no-content does download them.

If the largefiles expression needs the file content available
(due to mimetype or mimeencoding being used), the import will fail.

This commit was sponsored by Jake Vosloo on Patreon.

split ProvidedInfo and UserProvidedInfo

The latter is for git-annex matchexpression and matching against it can
throw an exception. Splitting out the former reduces the potential for
mistakes and avoids needing to worry about matching against that
throwing an exception.

This is more groundwork for matching largefiles while importing,
without downloading content.

This commit was sponsored by Graham Spencer on Patreon.

allow matching on files whose content is not present

Anything that needs to examine the file content will fail to match,
or fall back to other available information. But the intent is that the
matcher be checked for matchNeedsFileContent and only be used if it does
not, so the exact behavior doesn't much matter as it should never
happen.

The real point of this is to not need to provide a dummy content file
when matching.

This commit was sponsored by Martin D on Patreon.

split out todo

close as unreproducible

moreinfo

close

Added a comment

Added a comment: NeuroDebian seems to have stopped updating

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

add todo

Added a comment

remove reapZombies

Believed to be no longer needed as I've squashed the last ones.

Note that, in Test.Framework, I can see no reason for the code to have
run it twice. It does not cause running processes to exit after all,
so any process that has leaked and is running and causing problems with
cleanup of the directory won't be helped by running it.

This commit was sponsored by Mark Reidenbach on Patreon.

remove zombie process in file seeking

This was the last one marked as a zombie. There might be others I don't
know about, but except for in the hypothetical case of a thread dying
due to an async exception before it can wait on a process it started, I
don't know of any.

It would probably be safe to remove the reapZombies now, but let's wait
and so that in its own commit in case it turns out to cause problems.

This commit was sponsored by Boyd Stephen Smith Jr. on Patreon.

fix build warning

explicitly wait for a git process

Eliminate a zombie that was only cleaned up by the later zombie cleanup
code.

This is still not ideal, it would be cleaner if it used conduit or
something, and if the thread gets killed before waiting, it won't stop
the process.

Only remaining zombies are in CmdLine.Seek

devblog (for yesterday, forgot to add)

fix some compile warnings left in yesterday

at least 2 could have caused a crash in some circumstances

This commit was sponsored by Brett Eisenberg on Patreon.

seek: defer matcher check until more info is known

Sped up seeking for files to operate on, when using options like --copies
or --in, by around 20%.

Benchmark showed an increase for --copies from 155 seconds to 121
seconds, and --in remote will be similar to that.

For --in here, the speedup was less, 5-10% or so.

(both warm cache)

This commit was sponsored by Jack Hill on Patreon.

close this

phibs who was seeing hangs confirmed they're gone on irc

fix some matchNeedsFileName values

matchMagic: Always False for MatchingKey. Unsure why.. Could be a bug?

limitUnused: Behaves differently when there is a filename.

limitSize: When used with LimitDiskFiles, checks the size on disk of the
filename.

remove debug print

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

sync --all avoid unncessary first pass

Sped up seeking to around twice as fast, by avoiding a pass over the
worktree files when preferred content expressions of the local repo and
remotes don't use include=/exclude=.

Thanks to Lukey for identifying the optimisation.

This commit was sponsored by Brock Spratlen on Patreon.

Added a comment

wait for first pass to complete before second pass

Otherwise the bloom filter may not be fully populated when the second
pass starts, which could have led to incorrect behavior with --all -J,
probably in very rare circumstances.

remove obsolete comment

make MatchFiles introspectable

matchNeedsFileContent is not used yet, but shows how to add information
about terminals. That one would be needed for
https://git-annex.branchable.com/todo/sync_fast_import/

Note the tricky bit in Annex.FileMatcher.call where it folds over the
included matcher to propagate the information.

This commit was sponsored by Svenne Krap on Patreon.

add meta todo

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

Improve --debug output to show pid of processes that are started and stopped

getPid returns Nothing if the process has already been stopped, and in that
case, the pid will not be displayed. I think that would only happen if
waitForProcess or similar gets called more than once on the same process
handle though.

getPid on unix has an overhead of only a MVar read. On Windows it needs to
make a syscall, so will be probably more expensive. While the added expense
happens even when debug logging is disabled, it should be small enough
compared with the overhead of starting a process that it's not a problem.

(It does occur to me that a debugM that took an IO String could only run it
when debugging is really enabled, which would improve performance. It does
not seem possible to use the current hslogger interface to do that though;
it does not expose the information that would be needed.)

Added a comment: is -J shared between workers and ASYNC or "multipliticative"?

initial TODO for making failure messages for processes be more informative

Improve the "Try making some of these repositories available" message

With some hints for the user for what to do.

Took care to avoid changing the json output. It would have been ok to add
the new separated lists to it, in addition to the old list, but I didn't
do that because I didn't see much point.

cache remote.log

Unlikely to speed up any of the existing uses much, but I want to use it
in a message that might be displayed many times.

fix typo

wording

comment

Added a comment

Added a comment

Added a comment

Added a comment: history of annexed file

Added a comment

Added a comment

make git-annex add --no-check-gitignore not skip ignored files, same as with --force

close

comment

Added --no-check-gitignore option for finer grained control than using --force.

add, addurl, importfeed, import: Added --no-check-gitignore option
for finer grained control than using --force.

(--force is used for too many different things, and at least one
of these also uses it for something else. I would like to reduce
--force's footprint until it only forces drops or a few other data
losses. For now, --force still disables checking ignores too.)

addunused: Don't check .gitignores when adding files. This is a behavior
change, but I justify it by analogy with git add of a gitignored file
adding it, asking to add all unused files back should add them all back,
not skip some. The old behavior was surprising.

In Command.Lock and Command.ReKey, CheckGitIgnore False does not change
behavior, it only makes explicit what is done. Since these commands are run
on annexed files, the file is already checked into git, so git add won't
check ignores.

comment

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

add missing CHECKURL-FAILURE ErrorMsg to docs

some whining about check-ignore

initial todo to add ErrorMsg to all -FAILURE responses

Serialize use of C magic library, which is not thread safe.

This fixes failures uploading to S3 when using -J.

This commit was sponsored by Denis Dzyubenko on Patreon.

comment

improve this comment

Added a comment: Re: comment 1

reproduced, some tcpdump analysis

comment

Added a comment: update

document bug i ran into early while exploring httpalso

Merge branch 'batchasync' into master

close

tip documenting mostly --batch --json including with -J

avoid interleaving command stages with Concurrency 1

Before, -J1 was different than no -J: It makes concurrent-output be used
for display, and it actually can run concurrent jobs in some situations.
Eg, a perform stage and a cleanup stage can both run.

dupState is used in several places, and changes NonConcurrent to
Concurrent 1. My concern is that this might, in some case, enable
that concurrent behavior. And in particular, that it might get enabled in
--batch mode, when the user is not expecting concurrent output because
they did not pass -J.

While I don't have a test case where that happens and causes out of
order output, it looks like it could, and so prudent to make this change.

support --batch -J

--batch combined with -J now runs batch requests concurrently for many
commands. Before, the combination was accepted, but did not enable
concurrency. Since the output of batch requests can be in any order, --json
with the new "input" field is recommended to be used, to determine which
batch request each response corresponds to.

If --json is not used, batch mode still runs concurrently, using the usual
concurrent-output. That will not be very useful for most batch mode users,
probably, but who knows.

If a program was using --batch -J before, and was parsing non-json output,
this could break it. But, it was relying on git-annex not supporting
concurrency despite it being enabled, so it should have expected concurrent
output. So, I think that's ok.

annex.jobs does not enable concurrency in --batch mode, because that would
confuse programs that use --batch but don't expect concurrency.

differentiate between concurrency enabled at command line and by git config

The latter should not affect --batch mode.

rename Configurable for clarity

remove callCommandAction'

This is prep for making batchCommandAction use commandAction,
which will enable concurrency for batch mode. Since commandAction can't
return anything, have to handle the case of a CommandStart that chooses
to do nothing in a different way.

refactor

batchStart folded into only caller

comment

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

groundwork complete

add "input" field to json output

The use case of this field is mostly to support -J combined with --json.
When that is implemented, a user will be able to look at the field to
determine which of the requests they have sent it corresponds to.

The field typically has a single value in its list, but in some cases
mutliple values (eg 2 command-line params) are combined together and the
list will have more.

Note that json parsing was already non-strict, so old git-annex metadata
--json --batch can be fed json produced by the new git-annex and will
not stumble over the new field.

use Branch.name instead of hard coding the branch name

Makes much more clear why ActionItemOther is being passed "git-annex".

add SeekInput (not yet used)

No behavior changes (hopefully), just adding SeekInput and plumbing it
through to the JSON display code for later use.

Over the course of 2 grueling days.

withFilesNotInGit reimplemented in terms of seekHelper
should be the only possible behavior change. It seems to test as
behaving the same.

Note that seekHelper dummies up the SeekInput in the case where
segmentPaths' gives up on sorting the expanded paths because there are
too many input paths. When SeekInput later gets exposed as a json field,
that will result in it being a little bit wrong in the case where
100 or more paths are passed to a git-annex command. I think this is a
subtle enough problem to not matter. If it does turn out to be a
problem, fixing it would require splitting up the input
parameters into groups of < 100, which would make git ls-files run
perhaps more than is necessary. May want to revisit this, because that
fix seems fairly low-impact.

Added a comment

few more details

info gathered from irc

aws-0.22 improved its support for setting etags, which improves support for versioned S3 buckets.

Remove placeholder version number I used when implementing the feature in
aws.

This commit was sponsored by Ethan Aubin.

point to commit that may fix this

deepseq all things returned from ResourceT http

Potentially fixes https://git-annex.branchable.com/bugs/concurrent_git-annex-copy_to_s3_special_remote_fails/
although I don't know if it does.

My thinking is, ResourceT may allocate a resource and then free it,
and a unforced thunk to that resource could result in reading memory
that has since been overwritten by something else, or in a SEGV,
depending. While that seems kind of like a bug in ResourceT to me, if it
is what's happening, this will avoid it. If it's not, this doesn't
really hurt much since the values are all smallish.

This commit was sponsored by Graham Spencer on Patreon.

close as dup

close as dup