close

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

Added a comment

fromkey unlocked files support

fromkey: Create an unlocked file when used in an adjusted branch where the
file should be unlocked, or when configured by annex.addunlocked.

There is some overlap with code in Annex.Ingest, however it's not quite the
same because ingesting has a temp file with the content, where here the
content, if any, is in the annex object file. So it eg, makes sense for
Annex.Ingest to copy the execute mode of the content file, but it does not make
sense for fromkey to do that.

Also changed in passing to stage the file in git directly, rather than
using git add. One consequence of that is that if the file is gitignored,
it will still get added, rather than the old behavior:

The following paths are ignored by one of your .gitignore files:
ignored
hint: Use -f if you really want to add them.
hint: Turn this message off by running
hint: "git config advice.addIgnoredFile false"
git-annex: user error (xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"] exited 123)

That old behavior was a surprise to me, and so I consider it a bug, and doubt
anyone would have relied on it.

Note that, when on an --hide-missing branch, it is possible to fromkey a key
that is not present (needs --force). The annex link or pointer file still gets
written in this case. It doesn't seem to make any sense not to write it,
because then fromkey would not do anything useful in this case, and this way
the file can be committed and synced to master, and the branch re-adjusted to
hide the new missing file.

This commit was sponsored by Noam Kremen on Patreon.

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

Added a comment

removed

Added a comment

Added a comment

Added a comment

update

Added a comment

Added a comment

Added a comment

Added a comment

initial todo asking for possibility to assign costs per URL

initial todo for perspective copy-key(file) command(s)

added suggestion: support tree-ish in command args

Added a comment: openSUSE Leap 15.2

doc/git-annex-config: Fix typo in annex.synconlyannex description

add news item for git-annex 8.20210428

releasing package git-annex version 8.20210428

Added a comment: I think I am having the same issue

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

close

test case ran for over an hour successfully

Avoid more than 1 gpg password prompt at the same time

Which could happen occasionally before when concurrency is enabled.
While not much of a problem when it did happen, better to avoid it. Also,
since it seems likely the gpg-agent sometimes fails in such a situation,
this makes it not happen when running a single git-annex command with
concurrency enabled.

This commit was sponsored by Jake Vosloo on Patreon.

reproduced, some analysis of a gpg bug

This commit was sponsored by Graham Spencer on Patreon.

add missing whitespace

Added a comment

improve message

Pluralize copies appropriately.

This commit was sponsored by Mark Reidenbach on Patreon.

check mincopies is satisfied even when numcopies is known to be satisfied

I had been assuming that numcopies would be a larger or at most equal to
mincopies, so no need to check both. But users get confused and use configs
that don't really make sense, so make sure to handle mincopies being larger
than numcopies.

Also add something to the mincopies man page to discourage this
misconfiguration.

This commit was sponsored by Denis Dzyubenko on Patreon.

fix pasto

remove "checking remotename" message

This fixes fsck of a remote that uses chunking displaying
(checking remotename) (checking remotename)" for every chunk.

Also, some remotes displayed the message, and others did not, with no
consistency. It was originally displayed only when accessing remotes
that were expensive or might involve a password prompt, I think, but
nothing in the API said when to do it so it became an inconsistent mess.

Originally I thought fsck should always display it. But it only displays
in fsck --from remote, so the user knows the remote is being accessed,
so there is no reason to tell them it's accessing it over and over.

It was also possible for git-annex move to sometimes display it twice,
due to checking if content is present twice. But, the user of move
specifies --from/--to, so it does not need to display when it's
accessing the remote, as the user expects it to access the remote.

git-annex get might display it, but only if the remote also supports
hasKeyCheap, which is really only local git remotes, which didn't
display it always; and in any case nothing displayed it before hasKeyCheap,
which is checked first, so I don't think this needs to display it ever.

mirror is like move. And that's all the main places it would have been
displayed.

This commit was sponsored by Jochen Bartl on Patreon.

comment

git-annex-config: Allow setting annex.securehashesonly

Which has otherwise been supported since 2019, but was missing from the
list of allowed repo-global configs.

Reordered the list to match the order in the git-annex-config man page, to
make them easy to cross-compare.

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

response and close

comment

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

update

Added a comment

Added a comment

Added a comment

removed

Added a comment

Added a comment

Added a comment: Still happening

Added a comment

Added a comment: sparse checkouts to hide non-present files

Added a comment: try to find a better solution

removed

Added a comment: try to find a better solution

removed

Added a comment

remove misleading para

moving journal-private to journal risks losing other lines from the log
files

add note to git-annex-log man page about when information is not available

done

initremote --private

consistent name for config

annex.private is a bit ambiguous about what kind of privacy, but
it keeps the name symmetric with remote.foo.annex-private.

implement annex.privateremote and remote.name.private configs

The slightly unusual parsing in Types.GitConfig avoids the need to look
at the remote list to get configs of remotes. annexPrivateRepos combines
all the configs, and will only be calculated once, so it's nice and
fast.

privateUUIDsKnown and regardingPrivateUUID now need to read from the
annex mvar, so are not entirely free. But that overhead can be optimised
away, as seen in getJournalFileStale. The other call sites didn't seem
worth optimising to save a single MVar access. The feature should have
impreceptable speed overhead when not being used.

make remoteKeyToRemoteName safer

If it's passed a ConfigKey such as annex.version, avoid returning
an empty remote name and return Nothing instead. Also, foo.bar.baz is
not treated as a remote named "bar".

fix build after merge

Merge branch 'master' into hiddenannex

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

importfeed: fix bug while also speeding up 12x!

* Fix bug that could make git-annex importfeed not see recently recorded
  state when configured with annex.alwayscommit=false.
* importfeed: Made "checking known urls" phase run 12 times faster.

The massive speedup is because it no longer queries for metadata
accompanying each url. Instead it processes the whole git-annex branch and
checks all metadata files for feed item ids, and uses any it finds.

This could result in a behavior change, in an unlikely situation: If a feed
id is recorded in a key's metadata, but the url gets removed, the old code
would not see that item id and would re-download it if it finds an url for
it in a feed, while the new code will see the item id. I don't think
the old behavior was intentional, and it may be that the new behavior is
better. Not gonna worry about this.

refactoring

removed

convert withKnownUrls to use overBranchFileContents

This only partly fixes importfeed to see journalled files, since it
separately cats metadata directly from the branch. Held off on a
changelog for a bug fix until that's dealt with.

Revert "reorder another test"

This reverts commit 3e63f00f636eac897d58264733ec34d400598b19.

windows needs to die

close old bug

rename forum post that breaks windows checkout

at least sometimes, not on the autobuilder. I think git treats the ...
as a possible path traveral or something

update

reorder another test

continuing to try to narrow down cause of failure on windows

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

Added a comment

update

Added a comment

comment

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

alternative

docs

got private repos really working

This new TODO will need private indexes to resolve; until then the
private journal has to be checked when private UUIDs are known.

optimisation

Avoid trying to read private journal files when no private uuids are
known.

adapt recent bug fixes to support private journal

At this point, private repos should mostly work, except for a few
commands that directly read from the git-annex branch and will not see
the private journal.

Private index not yet implemented.

Merge branch 'master' into hiddenannex

fix --all to include not yet committed files from the journal

Fix bug caused by recent optimisations that could make git-annex not see
recently recorded status information when configured with
annex.alwayscommit=false.

This does mean that --all can end up processing the same key more than once,
but before the optimisations that introduced this bug, it used to also behave
that way. So I didn't try to fix that; it's an edge case and anyway git-annex
behaves well when run on the same key repeatedly.

I am not too happy with the use of a MVar to buffer the list of files in the
journal. I guess it doesn't defeat lazy streaming of the list, if that
list is actually generated lazily, and anyway the size of the journal is
normally capped and small, so if configs are changed to make it huge and
this code path fire, git-annex using enough memory to buffer it all is not a
large problem.

refactoring

fix branch precacheing bug by checking journal

Fix bug caused by recent optimisations that could make git-annex not see
recently recorded status information when configured with
annex.alwayscommit=false.

When not using --all, precaching only gets triggered when the
command actually needs location logs, and so there's no speed hit there.

This is a minor speed hit for --all, because it precaches even when the
location log is not actually going to be used, and so checking the journal
is not necessary. It would have been possible to defer checking the journal
until the cache gets used. But that would complicate the usual Branch.get
code path with two different kinds of caches, and the speed hit is really
minimal. A better way to speed up --all, later, would be to avoid
precaching at all when the location log is not going to be used.

wip

bug report

Merge branch 'master' into hiddenannex