Added a comment

Added a comment

Added a comment

comment

comment

response

comment and todo

remove my comment as someone else already answered it well

response

Added a comment

Added a comment

fix test that broke due to fromkey improvements

4588668a12f4f9b43cd6875b8ff45d7f3f6ffb1a made fromkey honor adjusted
unlocked branches. Also, it can be used on a crippled filesystem now.

smudge: check for known annexed inodes before checking annex.largefiles

smudge: Fix a case where an unlocked annexed file that annex.largefiles
does not match could get its unchanged content checked into git, due to git
running the smudge filter unecessarily.

When the file has the same inodecache as an already annexed file,
we can assume that the user is not intending to change how it's stored in
git.

Note that checkunchangedgitfile already handled the inverse case, where the
file was added to git previously. That goes further and actually sha1
hashes the new file and checks if it's the same hash in the index.

It would be possible to generate a key for the file and see if it's the
same as the old key, however that could be considerably more expensive than
sha1 of a small file is, and it is not necessary for the case I have, at
least, where the file is not modified or touched, and so its inode will
match the cache.

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