remove content of now independent issue https://git-annex.branchable.com/bugs/copy_--from_--to_does_not_copy_if_present_locally/

initial dedicated issue on copy --from --to not copying if present locally

initial report on --fast of being no effect for copy --from --to

Added a comment

Added a comment

Added a comment

Added a comment: I guess this question is about backends

added bug report for git init on a worktree checked out for a submodule.

Added a comment

Added a comment

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

git-annex log --gnuplot

The gnuplot output is pretty good, but could still be improved with:

* more colors (repeating colors is confusing with a lot of repos)
* better positioning of the legend, making the plot wider and moving it
  from over top of the graph

Sponsored-by: Kevin Mueller on Patreon

git-annex log --received modifier option

Only counting received and not dropped makes this show the bandwidth of
data coming into the repository, although only in a sense. Since
git-annex branch updates only happen at the end of a command, and we
don't know when a command started, it's only an approximation of the
actual bandwidth. (A previous git-annex branch update made have
happened in a different repository.)

It would be possible to also add a --dropped option, but I don't know
how useful that would be?

Sponsored-by: Nicholas Golder-Manning on Patreon

rename --when to --interval

More accurately describes its behavior.

close

guard against wrong timestamps in git log

For example, my sound repo has in the git-annex branch a commit from
2036, which is followed by one from 2034, in amoung commits from 2013.
Clearly there was a problem with the clock.

Since git log --date-order has a behavior of
"Show no parents before all of its children are shown", the data still
gets processed ok. The future timestamp just prevented displaying data
after that commit. It seems better, when the clock was wrong, to display
a wrong date, and then return to right dates.

It would be nice to filter out the wrong dates from display entirely,
but that seems it would need to buffer the whole output. This command is
too slow to buffer it all before displaying anything, and anyway this
kind of problem is probably rare.

Sponsored-by: Joshua Antonishen on Patreon

treat dead repos as 0 size

With this, git annex log --totalsizes can be compared with
git-annex info's "combined annex size of all repositories"
to double-check it works correctly.

In my sound repo, the two match.

In my big repo, the two report slightly different sizes,
with the former being 1.3 gb smaller than the latter.
I don't know the reason for this disreprency. Given the 30+tb size of
the repo, it's a small difference.

It seems possible that a bug in an old version of git-annex could
explain it. Eg, if an old git-annex lost a line when updating trust.log
or a location log in a merge, git-annex info would see only what it
replaced it with, while git-annex log will see the previous value as
well.

Sponsored-by: Leon Schuermann on Patreon

newtype MapLog

Noticed that Semigroup instance of Map is not suitable to use
for MapLog. For example, it behaved like this:

ghci>  parseTrustLog "foo 1 timestamp=10\nfoo 2 timestamp=11" <> parseTrustLog "foo X timestamp=12"
fromList [(UUID "foo",LogEntry {changed = VectorClock 11s, value = SemiTrusted})]

Which was wrong, it lost the newer DeadTrusted value.

Luckily, nothing used that Semigroup when operating on a MapLog. And this
provides a safe instance.

Sponsored-by: Graham Spencer on Patreon

git-annex log --totalsizes

Note that dead repositories are not yet handled so their sizes show as
nonzero after they are marked dead.

Sponsored-By: unqueued on Patreon

update

git-annex log --sizes

CSV format so it can be fed into a program to graph it.

Note that dead repositories are not yet handled so their sizes show as
nonzero after they are marked dead.

Sponsored-By: k0ld on Patreon

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

Added a comment

the last line is for the current time

git-annex log --sizesof

This can take a lot of memory. I decided to violate the usual rule in
git-annex that it operate in constant memory no matter how many annexed
objects. In this case, it would be hard to be fast without using a big
map of the location logs. The main difficulty here is that there can be
many git-annex branches and it needs to display a consistent view at a
point in time, which means merging information from multiple git-annex
branches.

I have not checked if there are any laziness leaks in this code. It
takes 1 gb to run in my big repo, which is around what I estimated
before writing it.

2 options that are documented are not yet implemented.

Small bug: With eg --when=1h, it will display at 12:00 then 1:10 if the
next change after 12:59 is then. Then it waits until after 2:10 to
display the next change. It ought to wait until after 2:00.

Sponsored-by: Brock Spratlen on Patreon

split out generic git log parser

Sponsored-By: Jack Hill on Patreon

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

todo

info: Added calculation of combined annex size of all repositories

Factored out overLocationLogs from CmdLine.Seek, which can calculate this
pretty fast even in a large repo. In my big repo, the time to run git-annex
info went up from 1.33s to 8.5s.

Note that the "backend usage" stats are for annexed files in the working
tree only, not all annexed files. This new data source would let that be
changed, but that would be a confusing behavior change. And I cannot
retitle it either, out of fear something uses the current title (eg parsing
the json).

Also note that, while time says "402108maxresident" in my big repo now,
up from "54092maxresident", top shows the RES constant at 64mb, and it
was 48mb before. So I don't think there is a memory leak. I tried using
deepseq to force full evaluation of addKeyCopies and memory use didn't
change, which also says no memory leak. And indeed, not even calling
addKeyCopies resulted in the same memory use. Probably the increased memory
usage is buffering the stream of data from git in overLocationLogs.

Sponsored-by: Brett Eisenberg on Patreon

improve comments

Added a comment: What about temporary annex.private declaration?

Added a comment

expand description

Added a comment

report

windows hook scripts newlines without CR

Windows: When git-annex init is installing hook scripts, it will
avoid ending lines with CR for portability.

Existing hook scripts that do have CR line endings will not be changed.
While it would be possible to have git-annex init upgrade them, users would
need to know to use that command to do that, and it would add complexity
that does not seem warranted for the portability benefit alone.

Sponsored-by: Luke T. Shumaker on Patreon

convert StorableCipher to ByteString

This allows getting rid of the ugly and error prone handling of
"bag of bytes" String in Remote.Helper.Encryptable.
Avoiding breakage like that dealt with by commit
9862d64bf90de645ef1acfbf862c5b340475aacf

And allows converting Utility.Gpg to use ByteString for IO, which is
a welcome change.

Tested the new git-annex interoperability with old, using all 3
encryption= types.

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

remove unused import

bring back "bag of bytes" handling for ciphers

Fixes test suite failure with LANG=C caused by commit
3742263c99180d1391e4fd51724aae52d6d02137

Sponsored-By: the NIH-funded NICEMAN (ReproNim TR&D3) project

reproduced

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

update

update

update

initial bug report

Added a comment

lookupkey: Sped up --batch

When the file is relative, it does not need to be passed
through git lsfiles to normalize it.

Sponsored-by: Kevin Mueller on Patreon

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

comment

Windows: Consistently avoid ending output lines with CR

This matches the behavior of git on Windows, which does not end lines with
CR either.

Previously, git-annex used to always write lines with putStrLn, so would
output CR on Windows. Then parts of it changed to use ByteString.putStrLn,
which does not output CR. That left its output inconsistent, sometimes
within the same command.

The point of this commit is to get back to consistency. Having the same
behavior as git is a nice bonus. It would be much harder to make it
consistently output CR, because every place it uses ByteString.putStrLn or
similar would need to be changed.

Sponsored-by: Nicholas Golder-Manning on Patreon

Windows: Fix CRLF handling in some log files

In particular, the mergedrefs file was written with CR added to each line,
but read without CRLF handling. This resulted in each update of the file
adding CR to each line in it, growing the number of lines, while also
preventing the optimisation from working, so it remerged unncessarily.

writeFile and readFile do NewlineMode translation on Windows. But the
ByteString conversion prevented that from happening any longer.

I've audited for other cases of this, and found three more
(.git/annex/index.lck, .git/annex/ignoredrefs, and .git/annex/import/). All
of those also only prevent optimisations from working. Some other files are
currently both read and written with ByteString, but old git-annex may have
written them with NewlineMode translation. Other files are at risk for
breakage later if the reader gets converted to ByteString.

This is a minimal fix, but should be enough, as long as I remember to use
fileLines when splitting a ByteString into lines. This leaves files written
using ByteString without CR added, but that's ok because old git-annex has
no difficulty reading such files.

When the mergedrefs file has gotten lines that end with "\r\r\r\n", this
will eventually clean it up. Each update will remove a single trailing CR.

Note that S8.lines is still used in eg Command.Unused, where it is parsing
git show-ref, and similar in Git/*. git commands don't include CR in their
output so that's ok.

Sponsored-by: Joshua Antonishen on Patreon

add PackageImports

This makes loading it in ghci work when both crypton and cryptonite are
installed.

Report on a possibly unknown slowness of `lookupkey`

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

remove wrongly nested comment

This happened to prevent checkout on windows, due to filename too long.

Added a comment

comment

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

display summary after concurrent output is complete

Otherwise, it could have buffered output that was displayed after the
summary. I started seeing that on my 12 core laptop, probably due to the
increased amount of concurrency.

Also seems possible, that, since the summary did exit, it might have
prevented displaying buffered output sometimes, or had other bad
results.

avoid unused import

simplify

RawFilePath conversion

May slightly speed up startup.

Added a comment

avoid double RawFilePath conversion

Minor optimisation.

push RawFilePath down into Annex.ReplaceFile

Minor optimisation, but a win in every case, except for a couple where
it's a wash.

Note that replaceFile still takes a FilePath, because it needs to
operate on Chars to truncate unicode filenames properly.

eliminate s2w8 and w82s

Note that the use of s2w8 in genUUIDInNameSpace made it truncate unicode
characters. Luckily, genUUIDInNameSpace is only ever used on ASCII
strings as far as I can determine. In particular, git-remote-gcrypt's
gcrypt-id is an ASCII string.

simplify base64 to only use ByteString

Note the use of fromString and toString from Data.ByteString.UTF8 dated
back to commit 9b93278e8abe1163d53fbf56909d0fe6d7de69e9. Back then it
was using the dataenc package for base64, which operated on Word8 and
String. But with the switch to sandi, it uses ByteString, and indeed
fromB64' and toB64' were already using ByteString without that
complication. So I think there is no risk of such an encoding related
breakage.

I also tested the case that 9b93278e8abe1163d53fbf56909d0fe6d7de69e9
fixed:

git-annex metadata -s foo='a …' x
git-annex metadata x
metadata x
  foo=a …

In Remote.Helper.Encryptable, it was avoiding using Utility.Base64
because of that UTF8 conversion. Since that's no longer done, it can
just use it now.

add

comment

comment

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

remove an out of date comment

The mentioned todo was closed.

speed up populating the importfeed database

Avoid conversion from ByteString to String for urls that will just be
converted right back to ByteString to go into the database.

Also setTempUrl is not used by importfeed, so avoid checking for temp
urls in this code path.

This benchmarks as only a small improvement. From 2.99s to 2.78s
when populating a database with 33k urls.

Note that it does not seem worth replacing URLString with URLByteString
generally, because the ways urls are used all entails either parseURI,
which takes a string, or passing a parameter to eg curl, which also is
currently a string.

Sponsored-by: Leon Schuermann on Patreon

Brainstorm (semi)automatic description updating

comment

Improve memory use of --all when using annex.private

This does not improve Annex.Branch.files at all, since it still uses ++ to
combine the lists, so forcing all but the last one.

But when there are a lot of files in the private journal, it does avoid
--all (or a bare repo) from buffering the filenames in memory.

See commit 653b7194727a27dfd185cdb0b752f8e190250fc4 for prior discussion of
this buffering.

Sponsored-by: Graham Spencer on Patreon

Added a comment: Minimum required version

Added a comment: Outdated?

sqlite datbase for importfeed

importfeed: Use caching database to avoid needing to list urls on every
run, and avoid using too much memory.

Benchmarking in my podcasts repo, importfeed got 1.42 seconds faster,
and memory use dropped from 203000k to 59408k.

Database.ImportFeed is Database.ContentIdentifier with the serial number
filed off. There is a bit of code duplication I would like to avoid,
particularly recordAnnexBranchTree, and getAnnexBranchTree. But these use
the persistent sqlite tables, so despite the code being the same, they
cannot be factored out.

Since this database includes the contentidentifier metadata, it will be
slightly redundant if a sqlite database is ever added for metadata. I
did consider making such a generic database and using it for this. But,
that would then need importfeed to update both the url database and the
metadata database, which is twice as much work diffing the git-annex
branch trees. Or would entagle updating two databases in a complex way.
So instead it seems better to optimise the database that
importfeed needs, and if the metadata database is used by another command,
use a little more disk space and do a little bit of redundant work to
update it.

Sponsored-by: unqueued on Patreon

update

update

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

improve docs

Added a comment

notabug

Added a comment

Added a comment

notabug

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

comment

Fix crash of enableremote when the special remote has embedcreds=yes

The crash occurred because writeCreds got called twice, and writeFileProtected
neglected to close its file handle, so the file was open for write when
written the second time.

It seems unncessary and suboptimal that writeCreds gets called twice.
One call is from getRemoteCredPair and the other from setRemoteCredPair'.
What happens is that in the enableremote case, code that also runs at
initremote does unncessary work. Might be possible to improve that, but
I've gone for the simple fix.

Sponsored-by: k0ld on Patreon

remove vim dev hack

This caused infinite recursion when I just used it, the dev target has
changed to re-run make. Anyway, not needed now.