better wording

add news item for git-annex 8.20211117

releasing package git-annex version 8.20211117

update git-lfs version to match git-annex.cabal

collapse lists of done items by default

Copying how the datalad page does it. This avoids me missing the header
and thinking these are still open.

tag moreinfo

comment

close

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

use parseFeedFromFile to avoid mojibake

As mentioned in commit 2bd778a46ed071c2dd534ebe3b7007b7ae60d1c1, there
was mojibake when LANG=C.

Looking at parseFeedFromFile, it is very particular to read the file as
unicode. parseFeedString looks like it will accept any old String,
but a String that was read using the filesystem encoding will not in
fact have the right encoding.

I think this is a bug in the feed library and will file one.

Sponsored-by: Svenne Krap on Patreon

importfeed: Fix a crash when used in a non-unicode locale

See comment for analysis.

At first I thought I'd need to convert all T.unpack in git-annex, but
luckily not -- so long as the Text is read from a file, the filesystem
encoding is applied and T.unpack is fine. It's only when using Feed
that the filesystem encoding is not applied.

While this fixes the crash, it does result in some mojibake, eg:
itemid=http://www.manager-tools.com/2014/01/choosing-a-company-work-chapter-7-���-questions/

Have not tracked that down, but it must be unrelated, because
I've verified that it roundtrips when using encodeUf8:

joey@darkstar:~/src/git-annex>LANG=C ghci  Utility/FileSystemEncoding.hs
ghci> useFileSystemEncoding
ghci> Just f <- Text.Feed.Import.parseFeedFromFile "/home/joey/tmp/career_tools_podcasts.xml"
ghci> Just (_, x) = Text.Feed.Query.getItemId (Text.Feed.Query.feedItems f !! 0)
ghci> decodeBS (Data.Text.Encoding.encodeUtf8 x)
"http://www.manager-tools.com/2014/01/choosing-a-company-work-chapter-7-\56546\56448\56467-questions/"
ghci> writeFile "foo" $ decodeBS (Data.Text.Encoding.encodeUtf8 x)
Writes a file containing the ENDASH character.

Sponsored-by: Jochen Bartl on Patreon

Added a comment

Added a comment

Added a comment

Added a comment

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

display error message if unable to run youtube-dl

This would have made the typo of the command name that was just fixed
obvious earlier, when --no-raw was used to force using it.

Fix a typo in the name of youtube-dl (reversion introduced in version 8.20210903)

improve docs

I saw a user open a forum post that looked like they had read this man
page, but were unaware of git-annex unlock, and were looking for its
functionality. They later deleted the post, probably when they found
git-annex unlock. Looking at this man page, it was a bit unclear about
the motivation for the command.

Yes, I'm warching... ;-)

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

migrate: New --remove-size option

While intended for converting URL keys added by addurl --fast to be
as if added by addurl --relaxed, it can also be used to remove size
from other types of keys. Although that is not likely to be useful
for checksummed keys, I suppose it could be used for WORM or other
non-checksum keys.

Specifying the --remove-size option does not prevent other migrations
from taking effect if there's a key upgrade to perform, or if the
backend has changed. So --backend=URL needs to be used to prevent
migrating an URL key to the default backend.

Note that it's not possible to use git-annex migrate to convert from a
non-URL key to an URL key, as URL keys cannot be generated, except by
addurl. So while this can get the same effect as --relaxed would have
when addurl --fast was used, when --fast was not used, it won't work, or
if --backend=URL is not used will remove the size but not prevent
checksum verification, which is not useful. Due to this complexity, I
decided not to mention it in the git-annex addurl man page.

Sponsored-by: Jochen Bartl on Patreon

Added a comment: It works

git-lfs gitlab interoperability fix

git-lfs: Fix interoperability with gitlab's implementation of the git-lfs
protocol, which requests Content-Encoding chunked.

Sponsored-by: Dartmouth College's Datalad project

tag as datalad

comment

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

new todo

Added a comment: clarification re: smudge filter and annex.supportunlocked

factor out IncrementalHasher from IncrementalVerifier

Added a comment

removed

uninit edge cases

* uninit: Avoid error message when no commits have been made to the
  repository yet.
* uninit: Avoid error message when there is no git-annex branch.

Sponsored-by: Svenne Krap on Patreon

comment

comment

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

devblog

dynamically disable filter-process in restagePointerFile when it would be slower

Based on my earlier benchmark, I have a rough cost model for how
expensive it is for git-annex smudge to be run on a file, vs
how expensive it is for a gigabyte of a file's content to be read and
piped through to filter-process.

So, using that cost model, it can decide if using filter-process will
be more or less expensive than running the smudge filter on the files to
be restaged.

It turned out to be *really* annoying to temporarily disable
filter-process. I did find a way, but urk, this is horrible. Notice
that, if it's interrupted with it disabled, it will remain disabled
until the next time restagePointerFile runs. Which could be some time
later. If the user runs `git add` or `git checkout` on a lot of small
files before that, they will see slower than expected performance.

(This commit also deletes where I wrote down the benchmark results
earlier.)

Sponsored-by: Noam Kremen on Patreon

Added a comment

Added a comment

Suggest description

benchmarking of filter-process vs smudge/clean

No firm conclusions yet, but it's doing better than I would have
expected.

Sponsored-by: Graham Spencer on Patreon

close

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

Revert "disable filter.annex.process in restagePointerFile"

This reverts commit afe327ac4947d6d32ff888e7485509be03d9baaf.

Unfortunately, disabling it by setting it to "" does not work, git
then ignores filter.annex.smudge/clean, and does not pass files through
git-annex at all.

I don't think there is a way to temporarily disable this git config
from the git command line. Which seems like a bug in git.

So, it may be more expensive than anticipated to enable
filter.annex.process, since git checkout etc will pipe all annexed files
being checked out through it.

update

update

Added a comment

restated: plenty of unit tests fail both under Windows and Ubuntu 18.04

plenty of unit tests fail on Windows

add pktLineHeaderLength

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

add filter.annex.process to bypassSmudgeConfig

disable filter.annex.process in restagePointerFile

This means git will run git-annex smudge --clean once per file that is
restaged, which can be slow. But probably *not* as slow as git feeding
all the content of annexed files you've gotten through a pipe to
git-annex filter-process.

The only time this is probably not ideal is after a drop of a bunch of
files, when filter-process would be faster.

update for git-annex filter-process

mention filter-process as v9 material

update with actual command to run

Merge branch 'master' into long-running-smudge

reorg

add git-annex filter-process

filter-process: New command that can make git add/checkout faster when
there are a lot of unlocked annexed files or non-annexed files, but that
also makes git add of large annexed files slower.

Use it by running: git
config filter.annex.process 'git-annex filter-process'

Fully tested and working, but I have not benchmarked it at all.
And, incremental hashing is not done when git add uses it, so extra work is
done in that case.

Sponsored-by: Mark Reidenbach on Patreon

handle unhandled case

shorten synopsis

This is to avoid the display being too wide.

removed

Added a comment

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

devblog

long-running-smudge branch started

git long-running filter process implementation

This module is not used yet, but the plan is to use it for smudge/clean
filtering, at least as an option. In some circumstances, using this
interface may perform better than the interface git-annex is currently
using.

Sponsored-by: Brock Spratlen on Patreon

git pkt-line implementation

This module is not used yet, but the plan is to implement
the long running filter process for smudge/clean.

Sponsored-by: Shae Erisson on Patreon

comment

comment

investigation results

Also, close dup bug.

tighter --json parsing for metadata

metadata --batch --json: Reject input whose "fields" does not consist of
arrays of strings. Such invalid input used to be silently ignored.

Used to be that parseJSON for a JSONActionItem ran parseJSON separately
for the itemAdded, and if that failed, did not propagate the error. That
allowed different items with differently named fields to be parsed.
But it was actually only used to parse "fields" for metadata, so that
flexability is not needed.

The fix is just to parse "fields" as-is. AddJSONActionItemFields is needed
only because of the wonky way Command.MetaData adds onto the started json
object.

Note that this line got a dummy type signature added,
just because the type checker needs it to be some type.
itemFields = Nothing :: Maybe Bool
Since it's Nothing, it doesn't really matter what type it is,
and the value gets turned into json and is then thrown away.

Sponsored-by: Kevin Mueller on Patreon

comment

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

metadata --batch: Avoid crashing when a non-annexed file is input

Turns out that CommandStart actions do not have their exceptions caught,
which is why the giveup was causing a crash. Mostly these actions
do not do very much work on their own, but it does seem possible there
are other commands whose CommandStart also throws an exception.

So, my first attempt at a fix was to catch those exceptions. But,
--json-error-messages then causes a difficulty, because in order to output
a json error message, an action needs to have been started; that sets up
the json object that the error message will be included in a field of.

While it would be possible to output an object with just an error field,
this would be json output of a format that the user has no reason to
expect, that happens only in an exceptional circumstance. That is something
I have always wanted to avoid with the json output; while git-annex man
pages don't document what the json looks like, the output has always
been made to be self-describing. Eg, it includes "error-messages":[]
even when there's no errors.

With that ruled out, it doesn't seem a good idea to catch CommandStart
exceptions and display the error to stderr when --json-error-messages
is set. And so I don't know if it makes sense to catch exceptions from that
at all. Maybe I'd have a different opinion if --json-error-messages did not
exist though.

So instead, output a blank line like other batch commands do.
This also leaves open the possibility of implementing support for matching
object with metadata --json, which would also want to output a blank line
when the input didn't match.

Sponsored-by: Dartmouth College's DANDI project

Added a comment

add news item for git-annex 8.20211028

releasing package git-annex version 8.20211028

fix addurl concurrency issue

addurl: Support adding the same url to multiple files at the same time when
using -J with --batch --with-files.

Implementation was easier than expected, was able to reuse OnlyActionOn.

While it will download the url's content multiple times, that seems like
the best thing to do; see my comment for why.

Sponsored-by: Dartmouth College's DANDI project

add a comment about checkSaneLock

See commit 8c2dd7d8ee814614bf3c871903b5d4d2aba193f4 for original
introduction of it, but needing to spelunk that far back to understand
the code is not good.

move transfer already in progress message to warning

This makes it be displayed in the error-messages field with
--json-error-messages. And with --quiet, it will let it be displayed,
which makes sense because it's telling the user why what they requested
to do has failed to happen.

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

comment

Added a comment

comment

avoid redundant freezeContent call

This opens the potential for the object file to be in place but
git-annex is interrupted before it can freeze it. git-annex fsck already
fixes that situation, which can also occur when lockContentForRemoval
thaws content.

Also improve comment to not be Windows-specific.

Added a comment

Call freezeContent after move into annex

This change better supports Windows ACL management using
annex.freezecontent-command and annex.thawcontent-command and matches
the behaviour of adding an unlocked file.

By calling freezeContent after the file has moved into the annex,
the file's delete permission can be denied. If the file's delete
permission is denied before moving into the annex, the file cannot
be moved or deleted. If the file's delete permission is not denied after
moving into the annex, it will likely inherit a grant for the delete
permission which allows it to be deleted irrespective of the permissions
of the parent directory.

comment

comment

update, bugfix also fixed git-annex info