Added a comment

Added a comment: comment 2

formatting

respond and close as not a bug

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

sped up git-annex smudge --clean by 25%

Disabling git-annex branch update for this command is
ok, because it does not use any information from the branch,
but only logs the location when it adds a key.

Sponsored-by: Dartmouth College's Datalad project

separate handles for cat-file and cat-file --batch-check

This avoids starting one process when only the other one is needed.
Eg in git-annex smudge --clean, this reduces the total number of
cat-file processes that are started from 4 to 2.

The only performance penalty is that when both are needed, it has to do
twice as much work to maintain the two Maps. But both are very small,
consisting of 1 or 2 items, so that work is negligible.

Sponsored-by: Dartmouth College's Datalad project

Added a comment

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

comment

Added a comment: v7 v v8 comparison

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

avoid potentially very long bwlimit delay at start

I first saw this getting with -J2 over ssh, but later saw it also
without the -J2. It was resuming, and the calulated unboundDelay was
many minutes. The first update of the meter jumped to some large value,
because of the resuming, and so it thought the BW was super fast.

Avoid by waiting until the second meter update.

Might be a good idea to also guard for the delay being many seconds
and avoid waiting. But how many? If BW is legitimately super fast, and a
remote happens to read more than a 32kb or so chunk at a time, it could
in theory download megabytes or gigabytes of data before the first meter
update. It would actually be appropriate then to delay for a long time,
if the desired BW was low. Could make up some numbers that are sane now,
but tech may improve.

(BTW, pleased to see bwlimit does work with -J. I had worried that
it might not, if the meter update happened in a different thread than
the downloading, but it's done in the same thread.)

Sponsored-by: Brett Eisenberg on Patreon

Added a comment

comment

followup

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

mention tiny wart

Merge branch 'bwlimit'

improved bwrate limiting implementation

New method is much better. Avoids unrestrained transfer at the beginning
(except for the first block. Keeps right at or a few kb/s below the
configured limit, with very little varation in the actual reported bandwidth.

Removed the /s part of the config as it's not needed.

Ready to merge.

Sponsored-by: Luke Shumaker on Patreon

Added a comment: Performance stats on crippled Debian NTFS-mount

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

note

simplify annex.bwlimit handling

RemoteGitConfig parsing looks for annex.bwlimit when a remote
does not have a per-remote config for it, so no need for a separate
gobal config.

Sponsored-by: Svenne Krap on Patreon

Merge branch 'master' into bwlimit

simplify annex.stalldetection handling

RemoteGitConfig parsing looks for annex.stalldetection when a remote
does not have a per-remote config for it, so no need for a separate
gobal config.

Sponsored-by: Noam Kremen on Patreon

fix remote git config vs global git config order

Bug fix: Git configs such as annex.verify were incorrectly overriding
per-remote git configs such as remote.name.annex-verify.

This dates all the way back to 2013,
commit 8a5b397ac47b21906f1fbb6254f5b70b3beb2a52,
where hlint apparently somehow confused me into parsing in the wrong
order. Before that it was correct.

Amazing noone has noticed until now.

Sponsored-by: Kevin Mueller on Patreon

Added a comment

bwlimit branch

resume properly when copying a file to/from a local git remote is interrupted

Probably this fixes a reversion, but I don't know what version broke it.

This does use withOtherTmp for a temp file that could be quite large.
Though albeit a reflink copy that will not actually take up any space
as long as the file it was copied from still exists. So if the copy cow
succeeds but git-annex is interrupted just before that temp file gets
renamed into the usual .git/annex/tmp/ location, there is a risk that
the other temp directory ends up cluttered with a larger temp file than
later. It will eventually be cleaned up, and the changes of this being
a problem are small, so this seems like an acceptable thing to do.

Sponsored-by: Shae Erisson on Patreon

bwlimit

Added annex.bwlimit and remote.name.annex-bwlimit config that works for git
remotes and many but not all special remotes.

This nearly works, at least for a git remote on the same disk. With it set
to 100kb/1s, the meter displays an actual bandwidth of 128 kb/s, with
occasional spikes to 160 kb/s. So it needs to delay just a bit longer...
I'm unsure why.

However, at the beginning a lot of data flows before it determines the
right bandwidth limit. A granularity of less than 1s would probably improve
that.

And, I don't know yet if it makes sense to have it be 100ks/1s rather than
100kb/s. Is there a situation where the user would want a larger
granularity? Does granulatity need to be configurable at all? I only used that
format for the config really in order to reuse an existing parser.

This can't support for external special remotes, or for ones that
themselves shell out to an external command. (Well, it could, but it
would involve pausing and resuming the child process tree, which seems
very hard to implement and very strange besides.) There could also be some
built-in special remotes that it still doesn't work for, due to them not
having a progress meter whose displays blocks the bandwidth using thread.
But I don't think there are actually any that run a separate thread for
downloads than the thread that displays the progress meter.

Sponsored-by: Graham Spencer on Patreon

comment

close as dup

comment

and reword possibly slightly confusing part of walkthrough

improve docs for refspec format

It was especially unclear that "reflog" did not need a leading "+".

response

comment

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

Added a comment: Should be safe

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

fixed a typo

Added a comment: Same here

Added a comment: Closing the loop

Added a comment

Added a comment

Added a comment

Added a comment

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

comment

Added a comment

Added a comment

response and close

Merge remote-tracking branch 'origin/master'

fix build with ghc 9.0.1

I was not able to test the whole build because of a very strange
Prelude.chr: bad argument: 469762054
Which I assume is a problem with this version of ghc or the way I was
using stack.

The stack.yaml that builds it used this patch

diff --git a/stack.yaml b/stack.yaml
index 790bffff2..8bcbaa0ec 100644
--- a/stack.yaml
+++ b/stack.yaml
@@ -1,6 +1,6 @@
 flags:
   git-annex:
-    production: true
+    production: false
     assistant: true
     pairing: true
     torrentparser: true
@@ -18,13 +18,15 @@ extra-deps:
 - IfElse-0.85
 - aws-0.22
 - bloomfilter-2.0.1.0
-- filepath-bytestring-1.4.2.1.6
-- git-lfs-1.1.0
-- http-client-restricted-0.0.3
+- filepath-bytestring-1.4.2.1.8
+- git-lfs-1.1.1
+- http-client-restricted-0.0.4
 - network-multicast-0.3.2
 - sandi-0.5
 - torrent-10000.1.1
 - bencode-0.6.1.1
+- base16-bytestring-0.1.1.7
+- base64-bytestring-1.0.0.3
 explicit-setup-deps:
   git-annex: true
-resolver: lts-16.27
+resolver: nightly-2021-09-07

some weird corner case that might be handled a little better?

comment

retitle

followup

close

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

update

Added a comment

test borg special remote

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

fix build

borg: Avoid trying to extract xattrs, ACLS, and bsdflags

when retrieving from a borg repository

That broke restoring on linux from a borg backup made on OSX.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

add news item for git-annex 8.20210903

releasing package git-annex version 8.20210903

Revert spam

This reverts commit e2038ef412bf6ddfe8ccb73bf2bc1af02480a7c5.

close

comment

comment

Added a comment: Automatically adding metadata can be very slow

close dup

defer write permissions checking in import until after copy to repo

This should complete the fix started in
6329997ac44691937f1d7fe6a71da3184237b13b, fixing the actual cause of the
test suite failure this time.

Sponsored-by: Dartmouth College's Datalad project

comment

reopen

fix windows build

Added a comment

Added a comment

add author meta

commit 9595a247a doesn't compile on Windows without reverting a small previous change

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

improve url download failure display

* When downloading urls fail, explain which urls failed for which
  reasons.
* web: Avoid displaying a warning when downloading one url failed
  but another url later succeeded.

Some other uses of downloadUrl use urls that are effectively internal use,
and should not all be displayed to the user on failure. Eg, Remote.Git
tries different urls where content could be located depending on how the
remote repo is set up. Exposing those urls to the user would lead to wild
goose chases. So had to parameterize it to control whether it displays urls
or not.

A side effect of this change is that when there are some youtube urls
and some regular urls, it will try regular urls first, even if the
youtube urls are listed first. This seems like an improvement if
anything, but in any case there's no defined order of urls that it's
supposed to use.

Sponsored-by: Dartmouth College's Datalad project

Added a comment

Added a comment

comment

Added a comment: clarification

fix test suite failure on windows

This was maybe a real bug too, although I don't know what circumstances
it would be a problem. See comment for analysis of this windows drive
letter wackyness issue.

Sponsored-by: Brock Spratlen on Patreon

close

skip test_readonly on windows

       drop vs readonly repo failed (transcript follows)
      drop foo
      failed
      git-annex: .git\annex\objects\6cd\e82\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77: DeleteFile "\\\\?\\C:\\Users\\runneradmin\\.t\\tmprepo3\\.git\\annex\\objects\\6cd\\e82\\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77": permission denied (Access is denied.)

This is a bit surprising, it seems that chmod -R -w on windows actually
had some effect. But also, on Windows lockContentShared
has to write to a lock file, so it cannot work in a readonly repo.
So git-annex cannot support readonly repos on Windows.

Sponsored-by: Dartmouth College's Datalad project