initremote type=git probe uuid

rather than matching path of an existing remote to find the uuid.

The main benefit of this is that locations not using ssh:// will work
now, including both paths and host:/path

The other benefit is that it's a simpler interface, no need to have an
existing remote with the same url and some other name. Although that
will still work of course.

This does rely on tryGitConfigRead working when given a Git.Repo that is
not a remote. Luckily, it works fine that way.

Also, tryGitConfigRead will auto-init a local repo that has a git-annex
branch. I did not enable auto-init of ssh repos though.

The uuid discovery actually happens twice; initremote discovers it,
and uses it to store the special remote config, but does not set it in the
git remote it creates. So the next run of git-annex does uuid discovery
again, and caches it that time. This could be improved for a tiny
speedup, but I didn't want to complicate things for that in this
commit.

Sponsored-by: Dartmouth College's DANDI project

bug report

analysis

comment

initial whining about type=git initremote

initial report on addurls issue

Added a comment

Added a comment

comment

add debugging around commits to sqlite dbs

comment

fix MVar deadlock when sqlite commit fails

The database queue was left empty, which caused subsequent calls to
flushDbQueue to deadlock.

Sponsored-by: Dartmouth College's Datalad project

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

Added a comment

Added a comment

Added a comment

update

Added a comment

add debugLocks around database operations

to track down a blocked indefinitely on MVar that seems to occur after
sqlite throws ErrorBusy but that I have not been able to reproduce when
I made commits synthetically throw ErrorBusy.

Sponsored-by: Dartmouth College's Datalad project

comment

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

close

Added a comment

Added a comment

Added a comment: still reports about invalid option but doesn't fail

Added a comment: defending BTRFS

ping

comment

close as hopefully fixed

did not have a good way to reproduce this, but I had a good theory about
a cause and fix..

close as already fixed

comment

update content of .git/info/attributes

This got changed but forgot to update it here.

info: Added --autoenable option

Use cases include using git-annex init --no-autoenable and then going back
and enabling the special remotes that have autoenable configured. As well
as just querying to remember which ones have it enabled.

It lists all special remotes that have autoenable=yes whether currently
enabled or not. And it can be used with --json.

I pondered making this "git-annex info autoenable", but that seemed wrong
because then if the use has a directory named "autoenable", it's unclear
what they are asking for. (Although "git-annex info remote" may be
similarly unclear.) Making it an option does mean that it can't be provided
via --batch though.

Sponsored-by: Dartmouth College's Datalad project

init: Added --no-autoenable option

Someone may disagree with what repositories are set to autoenable and
it's good to have local overrides.

See https://github.com/datalad/datalad/issues/6634

Sponsored-by: Dartmouth College's Datalad project

comment

Added a comment

Added a comment

removed

Added a comment

Added a comment

Added a comment

Added a comment

comment

moreinfo

comment

enable --as-needed on freebsd

based on doc/bugs/FreeBSD_patches.mdwn which indicates it works, though
sadly without anything more than a patch.

If this breaks anything it will be reverted.

comment

response

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

debug output of git security check probe

This is so, if there's some other failure that triggers it, --debug will
show what went wrong. See https://github.com/datalad/datalad/issues/6708

Sponsored-by: Dartmouth College's Datalad project

make path absolute for display

Avoid suggesting the user add "." to safe.directory.

Added a comment

added question re: exporttree=yes and versioned S3 remotes

Added a comment: adb sync problem (after some upgrades)

Added a comment: another/different? stall

Added a comment: What filesystem is this happening on?

add news item for git-annex 10.20220525

releasing package git-annex version 10.20220525

followup

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

fix git-annex test -p

test: When limiting tests to run with -p, work around tasty limitation by
automatically including dependent tests.

This fixes a reversion because it didn't used to use dependencies and
forced tasty to run the init tests first. That changed when parallelizing
the test suite.

It will sometimes do a little more work than strictly required,
because it adds init tests deps when limited to eg quickcheck tests,
which don't depend on them. But this only adds a few seconds work.

Sponsored-by: Dartmouth College's Datalad project

revert windows-specific locking changes that broke tests

This reverts windows-specific parts of 5a98f2d50913682c4ebe0e0c4ce695c450a96091
There were no code paths in common between windows and unix, so this
will return Windows to the old behavior.

The problem that the commit talks about has to do with multiple different
locations where git-annex can store annex object files, but that is not
too relevant to Windows anyway, because on windows the filesystem is always
treated as criplled and/or symlinks are not supported, so it will only
use one object location. It would need to be using a repo populated
in another OS to have the other object location in use probably.
Then a drop and get could possibly lead to a dangling lock file.

And, I was not able to actually reproduce that situation happening
before making that commit, even when I forced a race. So making these
changes on windows was just begging trouble..

I suspect that the change that caused the reversion is in
Annex/Content/Presence.hs. It checks if the content file exists,
and then called modifyContentDirWhenExists, which seems like it would
not fail, but if something deleted the content file at that point,
that call would fail. Which would result in an exception being thrown,
which should not normally happen from a call to inAnnexSafe. That was a
windows-specific change; the unix side did not have an equivilant
change.

Sponsored-by: Dartmouth College's Datalad project

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

fix typo in comment

some of the test log output I should've added; formatting

bug: commit 5a98f2d50 causes two failures to appear in repo tests on Windows

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

deal with git's changes for CVE-2022-24765

Deal with git's recent changes to fix CVE-2022-24765, which prevent using
git in a repository owned by someone else.

That makes git config --list not list the repo's configs, only global
configs. So annex.uuid and annex.version are not visible to git-annex.
It displayed a message about that, which is not right for this situation.
Detect the situation and display a better message, similar to the one other
git commands display.

Also, git-annex init when run in that situation would overwrite annex.uuid
with a new one, since it couldn't see the old one. Add a check to prevent
it running too in this situation. It may be that this fix has security
implications, if a config set by the malicious user who owns the repo
causes git or git-annex to run code. I don't think any git-annex configs
get run by git-annex init. It may be that some git config of a command
does get run by one of the git commands that git-annex init runs. ("git
status" is the command that prompted the CVE-2022-24765, since
core.fsmonitor can cause it to run a command). Since I don't know how
to exploit this, I'm not treating it as a security fix for now.

Note that passing --git-dir makes git bypass the security check. git-annex
does pass --git-dir to most calls to git, which it does to avoid needing
chdir to the directory containing a git repository when accessing a remote.
So, it's possible that somewhere in git-annex it gets as far as running git
with --git-dir, and git reads some configs that are unsafe (what
CVE-2022-24765 is about). This seems unlikely, it would have to be part of
git-annex that runs in git repositories that have no (visible) annex.uuid,
and git-annex init is the only one that I can think of that then goes on to
run git, as discussed earlier. But I've not fully ruled out there being
others..

The git developers seem mostly worried about "git status" or a similar
command implicitly run by a shell prompt, not an explicit use of git in
such a repository. For example, Ævar Arnfjörð Bjarma wrote:
> * There are other bits of config that also point to executable things,
>   e.g. core.editor, aliases etc, but nothing has been found yet that
>   provides the "at a distance" effect that the core.fsmonitor vector
>   does.
>
>   I.e. a user is unlikely to go to /tmp/some-crap/here and run "git
>   commit", but they (or their shell prompt) might run "git status", and
>   if you have a /tmp/.git ...

Sponsored-by: Jarkko Kniivilä on Patreon

Added a comment

response

comment

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

comment

datalad metadata

remove git-annex test runner segfault workarounds

Those segfaults were caused by setEnv, which should have been fixed by
commits 79017c612e16653d00253f6862b925b287102624 and
ebb76f0486030e1e6bae43b5f05d00d63a968681.

Sponsored-by: Dartmouth College's Datalad project

avoid setEnv in test framework when tasty is running

setEnv is not thread safe and could cause a getEnv by another thread to
segfault, or perhaps other had behavior. This is particularly a problem
when using tasty, because tasty runs the test in a thread, and a getEnv
in another thread.

The use of top-level TMVars is ugly, but ok because only 1 test actually
runs at a time per process. Because it has to chdir into the test repo.

The setEnv that remains happens before tasty is running.

Sponsored-by: Dartmouth College's Datalad project

avoid setEnv while testing gpg

setEnv is not thread safe and could cause a getEnv by another thread to
segfault, or perhaps other had behavior.

Sponsored-by: Dartmouth College's Datalad project

get got stuck

add comment I made earlier

comment and open a todo

initial report on stuck  conflict resolution (adjusted branch)

Added a comment

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

make fsck normalize object locations

The purpose of this is to fix situations where the annex object file is
stored in a directory structure other than where annex symlinks point to.

But it will also move object files from the hashdirmixed back to
hashdirlower if the repo configuration makes that the normal location.
It would have been more work to avoid that than to let it do it.

Sponsored-by: Dartmouth College's Datalad project

fix hardcoding of number of hash directories

It can be changed to 1 via a tuning, rather than the 2 this assumed. So
it would have tried to rmdir .git/annex/objects in that case, which
would not hurt anything, but is not what it is supposed to do.

Sponsored-by: Dartmouth College's Datalad project

avoid creating content directory when locking content

If the content directory does not exist, then it does not make sense to
lock the content file, as it also does not exist, and so it's ok for the
lock operation to fail.

This avoids potential races where the content file exists but is then
deleted/renamed, while another process sees that it exists and goes to
lock it, resulting in a dangling lock file in an otherwise empty object
directory.

Also renamed modifyContent to modifyContentDir since it is not only
necessarily used for modifying content files, but also other files in
the content directory.

Sponsored-by: Dartmouth College's Datalad project

Added a comment: How to disable lockdown in bare repos?

Added a comment: Using fuse

Added a comment: shell helper