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

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.

Added a comment

Added a comment

new bug: git annex enableremote locking issue

Added a comment: Rclone B2 vs S3

removed

Added a comment: Rsync vs S3

comment

only stage regular files from the journal

git-annex only writes regular files there, but other things may drop junk
like empty .DAV directories around the tree. And trying to hash such things
can have weird and hard to understand effects. So it seems best to do a
small amount of work in statting the journal file to make sure it's a
regular file.

Sponsored-by: Jack Hill on Patreon

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

Added a comment

Added a comment

comment

comment

comment

commnet

comment

don't say a supported version is unsupported

When an automatic upgrade from eg v10 fails, it's still a supported
version, so don't say unsupported.

Added a comment

Added a comment

Added a comment: Linux 64bit failing?

drop NSF logo

Seems hotlinking is not allowed, and I don't want to copy it to some
other site (can't include it here due to licensing.)

fix NSF logo

enable parallel ghc for building git-annex

Via a build flag this time, that's off by default because hackage
demands it be so, but that gets turned on by the Makefile and by stack.

Revert "enable parallel ghc for building git-annex"

This reverts commit 3f6aff89b1022b90c43a96b091d55e6e251d6f83.

Sadly hackage rejects cabal files using -j unless hidden behind an
option that is disabled by default.

add news item for git-annex 10.20230926

releasing package git-annex version 10.20230926

analysis

followup

update

close

close

close

close

close

moreinfo

argh

hmmm

hm

analysis

close as seems fixed

close

enableremote: Avoid overwriting existing git remote when passed the uuid of a specialremote that was earlier initialized with the same name

moreinfo

comment

done

typo

document -C behavior with exporttree remotes

comment

fix some build warnings from ghc 9.4.6

It now notices that a RepoLocation may not be Local, in which case
pattern matching on Local wouldn't do.

fix some build warnings from ghc 9.4.6

For some reason it doesn't notice that req must be a Req, because
the toplevel function matched on that.

enable parallel ghc for building git-annex

This drops a full recompile on my new 12 core laptop from 4:00 to 2:47.

It would be possible for me to use:
cabal configure --ghc-options=-j
But that also makes cabal parallelize ghc for each package it installs
to satisfy git-annex's dependencies. Since cabal is already configured
to parallize installing dependencies, that would use N^2 cpu cores,
which seems like a bad idea.

And also I'd have to remember to do it.

So I'm thinking it's better to do it by default. If a system that is
building git-annex is also busy with other things, let the scheduler
sort it out. If this impacts someone particularly badly, they can of
course avoid it with:
cabal configure --ghc-options=-j1

Support being built with crypton rather than cryptonite

crypton is a fork of cryptonite, and cryptonite's github repo has been
archived. Some deps are already using cryptonite so it's clearly the way
forward.

Added a build flag without a default, so cabal configure will select on its
own which to use. stack files pin to cryptonite for now.

Sponsored-by: Nicholas Golder-Manning on Patreon

fix some build warnings from ghc 9.4.6

It now notices that a RepoLocation may not be Local, in which case
pattern matching on Local wouldn't do.

However, in these cases, I think it always is a Local. In particular,
Git.Config.read is only run on local repos and upgrades LocalUnknown to
Local.

use unshorted hash in version

short hashes can be lengthened by unrelated pulls into a repo, breaking
reproducible builds
https://lists.reproducible-builds.org/pipermail/rb-general/2023-September/003072.html

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

new make dev target

rename old to make prof

silence build warning

about ~

todo

Added a comment

announcement

comment

remove incorrect documentation of annex.skipunknown behavior

git-annex get with no parameters and annex.skipunknown = false
in a directory with no files tracked by git results in the same
failure as with a "." parameter.

It may be that git ls-files --error-unmatch changed behavior? Or this
was just wrong.

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

lookupkey: Added --ref option

Sponsored-by: Joshua Antonishen on Patreon

Added a comment

Added a comment: just show start time?

propigateAdjustedCommits in seekExportContent

push: When on an adjusted branch, propagate changes to parent branch before
updating export remotes.

This is a somewhat redundant call to propigateAdjustedCommits, since it
also gets called at pushLocal time. That other one needs to come after
importing from importtree remotes though, and seekExportContent has to come
earlier, so I don't see a way to avoid doing it twice.

Note that git-annex sync also manages to avoid the problem, it's only
git-annex push that had the bug.

Sponsored-by: Leon Schuermann on Patreon

improve warning message when unable to update export

A misleading message was displayed in several cases.

If the user has run eg: git config
remote.push-win-remote.annex-tracking-branch 'adjusted/main(unlocked)'
That is not supported, and now it will tell them it's not a valid
configuration. A user reported doing that, but I don't know if it's a
common point of confusion. If it is a common problem, a better message
would be possible, or it could convert back from the adjusted branch to
the actual branch.

Sponsored-by: Graham Spencer on Patreon

comment (and close)

comment

add link