Added a comment

Added a comment: thanks

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

comment

Added a comment: recovering from sqlite db corruption

comment

close

comment

comment and close

Added a comment: an alternative

Added a comment: old comments

fix windows build

Added annex.freezecontent-command and annex.thawcontent-command configs

Freeze first sets the file perms, and then runs
freezecontent-command. Thaw runs thawcontent-command before
restoring file permissions. This is in case the freeze command
prevents changing file perms, as eg setting a file immutable does.
Also, changing file perms tends to mess up previously set ACLs.

git-annex init's probe for crippled filesystem uses them, so if file perms
don't work, but freezecontent-command manages to prevent write to a file,
it won't treat the filesystem as crippled.

When the the filesystem has been probed as crippled, the hooks are not
used, because there seems to be no point then; git-annex won't be relying
on locking annex objects down. Also, this avoids them being run when the
file perms have not been changed, in case they somehow rely on
git-annex's setting of the file perms in order to work.

Sponsored-by: Dartmouth College's Datalad project

remove dead code

comment

tag datalad

at yoh's request

comment

remove old android comments/bug reports

remove comment I made to the wrong place

I am not sure what forum thread I was intending to comment on

remove old closed bugs and todo items to speed up wiki updates and reduce size

Remove closed bugs and todos that were last edited or commented before 2020.

Except for ones tagged projects/* since projects like datalad want to keep
around records of old deleted bugs longer.

Command line used:

for f in $(grep -l '|done\]\]' -- ./*.mdwn); do if ! grep -q "projects/" "$f"; then d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2020 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2020 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; fi; done
for f in $(grep -l '\[\[done\]\]' -- ./*.mdwn); do if ! grep -q "projects/" "$f"; then d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2020 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2020 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; fi; done

remove unused import

push synced/master before synced/git-annex

sync: Partly work around github behavior that first branch to be pushed to
a new repository is assumed to be the head branch, by not pushing
synced/git-annex first.

github expects master (or whatever the name is) to be pushed first, but
git-annex sync can't, because it's got to also support pushes to non-bare
repos where pushing master fails, as explained in the big comment. So
pushing synced/master is not entirely a fix, but at least it makes github
default to a branch with the stuff the user expects in it, not a bunch of
annex log files.

Aside from fixing github to not make this assumption, or improving
the git push protocol to include what the current HEAD is, the only other
approach I can think of is to identify git push's progress messages and
display those when pushing master, while filtering out error messages
about non-fast-forward etc. But git doesn't provide a way to separate out
or identify its progress messages.

Sponsored-by: Luke Shumaker on Patreon

remove comment on now-deleted post

add news item for git-annex 8.20210621

releasing package git-annex version 8.20210621

comment

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

fix 2 build warnings

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment: setting up sync

Added a comment

Added a comment

Added a comment

Added a comment

added suggestion to allow use of synchronous=OFF with Sqlite

Added a comment: thanks

comment

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

Added a comment: adding disableremote

removed

Added a comment: adding disableremote

clear progress bar before displaying messages

In particular this clears it before "transfer stalled". If an external
special remote uses showInfo while progress is displayed, it will also
improve display of that.

Generally this will avoid all such problems in the future..

Sponsored-by: Svenne Krap on Patreon

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

removed

drop, move, mirror: when two files have the same content, honor the max numcopies and requiredcopies

Eg, before with a .gitattributes like:

*.2 annex.numcopies=2
*.1 annex.numcopies=1

And foo.1 and foo.2 having the same content and key, git-annex drop foo.1 foo.2
would succeed, leaving just 1 copy, despite foo.2 needing 2 copies.
It dropped foo.1 first and then skipped foo.2 since its content was gone.

Now that the keys database includes locked files, this longstanding wart
can be fixed.

Sponsored-by: Noam Kremen on Patreon

Added a comment

Added a comment

remove unused import

verify associated files when checking numcopies

Most of this is just refactoring. But, handleDropsFrom
did not verify that associated files from the keys db were still
accurate, and has now been fixed to.

A minor improvement to this would be to avoid calling catKeyFile
twice on the same file, when getting the numcopies and mincopies value,
in the common case where the same file has the highest value for both.
But, it avoids checking every associated file, so it will scale well to
lots of dups already.

Sponsored-by: Kevin Mueller on Patreon

fix build

avoid warning

avoid nub

It's O(N^2) which could matter when there are many dup files using the
same key.

refactor

close

respinse

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

fix exponential blowup when adding lots of identical files

This was an old problem when the files were being added unlocked,
so the changelog mentions that being fixed. However, recently it's also
affected locked files.

The fix for locked files is kind of stupidly simple. moveAnnex already
handles populating unlocked files, and only does it when the object file
was not already present. So remove the redundant populateUnlockedFiles
call. (That call was added all the way back in
cfaac52b88e157dd4e71626fe68af37015b9c9bd, and has always been
unncessary.)

Sponsored-by: Dartmouth College's Datalad project

remove supportUnlocked check that is not worth its overhead

moveAnnex only gets to that check if the object file was not present
before. So in the case where dup files are being added repeatedly,
it will only run the first time, and so there's no significant speedup
from doing it; all it avoids is a single sqlite lookup. Since MVar
accesses do have overhead, it's better to optimise for the common case,
where unlocked files are supported.

removeAnnex is less clear cut, but I think mostly is skipped running on
keys when the object has already been dropped, so similar reasoning
applies.

bloom doesn't work, but this should I hope

plan

comment

going round and round, boredly

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

comment

comment

Future proof activity log parsing

When the log has an activity that is not known, eg added by a future
version of git-annex, it used to be treated as no activity at all,
which would make git-annex expire think it should expire the repository,
despite it having some kind of recent activity.

Hopefully there will be no reason to add a new activity until enough
time has passed that this commit is in use everywhere.

Sponsored-by: Jake Vosloo on Patreon

Added a comment

comment

improve docs based on forum feedback

comment

fix windows build

comment

avoid sometimes expensive operations when annex.supportunlocked = false

This will mostly just avoid a DB lookup, so things get marginally
faster. But in cases where there are many files using the same key, it
can be a more significant speedup.

Added overhead is one MVar lookup per call, which should be small
enough, since this happens after transferring or ingesting a file,
which is always a lot more work than that. It would be nice, though,
to move getGitConfig to AnnexRead, which there is an open todo about.

response

Added a comment

Added a comment: git-annex-add slowdown

check symlink before reading file

This is faster because when multiple files are in a directory, it gets
cached.

retitle

reproduced

handle edge case of symlink to something that is not really a pointer file

That seems very unlikely to happen, but still, it's possible it could.
And with the recent addition of locked files to the keys db, this could
be called by places that did not call it before, so it seems even more
important it's correct.

Adds an extra stat of the file, and is potentially racy, but both
problems are fixed by the unix-2.8.0 path. I have not tested that path
builds because that package is not yet released and it would be difficult
to install it since it's tightly tied to a ghc version.

rename for clarity

Associated files are recorded now also for locked files, but this is
only needed to populate unlocked files.

Added a comment

Added a comment: more "mystery resolved" -- identical (empty) keys

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

comment

Added a comment

Added a comment