Added a comment

removed

Added a comment

Added a comment

Added a comment: My current use case

comment

update to work with modern git

comment

comment

fix reversion on skipping dead keys in --all/bare

Fix a reversion that made dead keys not be skipped when operating on all
keys via --all or in a bare repo. (Introduced in version 8.20200720)

Also, improved the documentation of git-annex-dead, it does not only apply
to fsck --all.

Also, made git-annex fsck, when run on a file whose key is dead, display
that. Before, it displayed that only when run with --all, but with this
fix, it skips dead keys with --all. But it can still be run on a file that
uses a dead key, and displaying "This key is dead" explains to the user
why it does not consider missing content for it to be a problem.

Sponsored-by: k0ld on Patreon

comment

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

comment

Added a comment

Added a comment: re: many small files

Added a comment: many small files

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

comment

Added a comment: re: How to forget keys that get can't find

comment

comment

comments

Added a comment

Added a comment

Added a comment

Added a comment: re: How to forget keys that get can't find?

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

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

don't force use of conduit in withUrlOptionsPromptingCreds

Use curl for downloads from git remotes when annex.url-options and other
git configs are set.

If the url needs a password, curl will fail, and git credential will not be
used to prompt for it. But the user can set --netrc in url-options and
put the password in the netrc file.

This also means that url-options settings like -4 will take effect.
That was the case before commit 1883f7ef8f9f617c60832c7f0794b54515fc652d
forced conduit to be used.

Added a comment: Using git-annex on NTFS with WSL2

comment

close

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

avoid redundant prompt for http password in git-annex get that does autoinit

autoEnableSpecialRemotes runs a subprocess, and if the uuid for a git
remote has not been probed yet, that will do a http get that will prompt
for a password. And then the parent process will subsequently prompt
for a password when getting annexed files from the remote.

So the solution is for autoEnableSpecialRemotes to run remoteList before
the subprocess, which will probe for the uuid for the git remote in the
same process that will later be used to get annexed files.

But, Remote.Git imports Annex.Init, and Remote.List imports Remote.Git,
so Annex.Init cannot import Remote.List. Had to pass remoteList into
functions in Annex.Init to get around this dependency loop.

cache credentials in memory when doing http basic auth to a git remote

When accessing a git remote over http needs a git credential prompt for a
password, cache it for the lifetime of the git-annex process, rather than
repeatedly prompting.

The git-lfs special remote already caches the credential when discovering
the endpoint. And presumably commands like git pull do as well, since they
may download multiple urls from a remote.

The TMVar CredentialCache is read, so two concurrent calls to
getBasicAuthFromCredential will both prompt for a credential.
There would already be two concurrent password prompts in such a case,
and existing uses of `prompt` probably avoid it. Anyway, it's no worse
than before.

Added a comment

comment

comment

reporting flaky tests on ndoli

Added a comment: git-credential-netrc

Added a comment

Added a comment

initial todo on multiple passwords entry for get

Added a comment

Added a comment

Added a comment

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

comment

Added a comment

comment

use getSymbolicLinkStatus not getFileStatus to avoid crash on broken symlink

Fix crash importing from a directory special remote that contains a broken
symlink.

The crash was in listImportableContentsM but some other places in
Remote.Directory also seemed like they could have the same problem.

Also audited for other places that have such a problem. Not all calls
to getFileStatus are bad, in some cases it's better to crash on something
unexpected. For example, `git-annex import path` when the path is a broken
symlink should crash, the same as when it does not exist. Many of the
getFileStatus calls are like that, particularly when they involve
.git/annex/objects which should never have a broken symlink in it.

Fixed a few other possible cases of the problem.

Sponsored-by: Lawrence Brogan on Patreon

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

fix build

update

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment: mtree can help

add NNCP special remote!

Added a comment: I don't think there is one

question about external drive filesystem

Added a comment: howto importfeed youtube playlists (not entire channels)

FTBFS report

Added a comment

update

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

optimise linker in linux standalone tarballs

Trick the linker into not doing unncessary work searching for optimised
libraries that are not present, by symlinking the directories where
optimised libs would be to the main lib dir.

This reduces the ENOENT of git-annex init by about 1/2. The linker always
finds the files where it looks first time now. I have not looked at what
the wall clock speedup might be, it's probably rather small.

If a x86-64-v5 comes to be, the list will need to be extended. And there
may be other directories used on some machines that I have missed. Not done
for arm64 yet, or any uncommon architectures.

Sponsored-by: Dartmouth College's Datalad project

comment

comment