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

update

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

fix dist in latest NEWS entry

Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>

Added a comment: standalone build version oddity

clarify first fsck call gave no output

removed

Added a comment

Added a comment

Added a comment: updating the standalone distribution to 8.20200908

removed

removed

Added a comment

Added a comment: Can I actually add a requirement like "at least two copies stored offsite" without specifying a particular repo?

initial report on the stuck test on osx

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

thoughts

Added a comment

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

todo

Added a comment

Added a comment: Re: Unknown remote type webdav

Added a comment: Re: Unknown remote type webdav

add news item for git-annex 8.20200908

releasing package git-annex version 8.20200908

reorder

Removed the S3 and WebDAV build flags

So these special remotes are always supported.

IIRC these build flags were added because the dep chains were a bit too
long, or perhaps because the libraries were not available in Debian stable,
or something like that. That was long ago, those reasons no longer apply,
and users get confused when builtin special remotes are not available, so
it seems best to remove the build flags now.

If this does cause a problem it can be reverted of course..

This commit was sponsored by Jochen Bartl on Patreon.

comment

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

avoid failure when gpgconf is not in path

followup

Added a comment: Unknown remote type webdav

resolvemerge: Improve cleanup of cruft left in the working tree  by a conflicted merge

This commit was sponsored by Jake Vosloo on Patreon.

clean up old code

withworktree is no longer doing anything useful so remove it

revert change that broke test suite

Opened a new bug about it.

This commit was sponsored by Ethan Aubin.

improve comment

devblog

avoid build warning

sync, assistant: When merge.directoryRenames is not set, default it it to "false"

Works better with automatic merge conflict resolution than git's ususual
default of "conflict".

This is not done when automatic merge conflict resolution is disabled.

This commit was sponsored by Mark Reidenbach on Patreon.

refactor

Make all calls to git merge go through autoMergeFrom, in preparation
for fine-tuning git merge's config for automatic merge conflict
resolution.

This commit was sponsored by Ryan Newton on Patreon.

update comments

resolvemerge: Improve cleanup of files that were deleted by one side of a conflicted merge, and modified by the other side

This case was handled by cleanConflictCruft, but only when the annexed
file's object was present. When not present, it left the annexed file
with the original name, not checked into git, while adding the variant
file. So, add an explicit deletion of the deleted file in this case.

My specific case where this happened actually involves
merge.directoryRenames=conflict. After a merge involving that,
the situation was the file appears as "added by them", because that
caused the file that they added to be moved into a directory we renamed.

That case is the same as them adding a modified version of the file,
while we deleted it. (Except for the history of the file, since it's a
new file, but this doesn't look at history.)

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

make automerge behavior when one side deleted explict

This does not actually change how the merge conflict is resolved when
one side deleted the file, but it was not documented before, and I think
it only worked by accident.

This commit was sponsored by Brett Eisenberg on Patreon.

more