update

comment

comment

response

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

sync: Fix parsing of gcrypt:: urls that use a relative path

Such an url is not valid; parseURI will fail on it. But git-annex doesn't
actually need to parse the url, because all it needs to do to support
syncing with it is know that it's not a local path, and use git pull and
push.

(Note that there is no good reason for the user to use such an url. An
absolute url is valid and I patched git-remote-gcrypt to support them
years ago. Still, users gonna do anything that tools allow, and
git-remote-gcrypt still supports them.)

Sponsored-by: Jack Hill on Patreon

comment

Added a comment

Added a comment

Added a comment: Understanding encrypted special remote folder structure

remove appveyor badge, which does not work

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

Added a comment

update appveyor config

got build caching working on windows
(The STACK_ROOT may be unncessary, or may be working around some kind of
bug that prevented build caching from working)

sped up build by disabling optimisation

fix build warnings on windows

Added a comment

add news item for git-annex 10.20230321

releasing package git-annex version 10.20230321

comment

comment

comment

not git-annex specific

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

this comment section is not a BTS, part N+1

Added a comment

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

Added a comment: RE: `git annex sync` not automatically syncing gcrypt remotes using relative paths

Added a comment: `git annex sync` not automatically syncing gcrypt remotes using relative paths

removed

Added a comment: `git annex sync` not syncing automatically with gcrypt remotes

add appveyor build badge

enable shallow clone to save my git server bandwidth

got appveyor build working

rename an old closed bug to avoid filename too long on windows checkout

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

initial appveyor file

Appveyor access provided by Michael Hanke. Once this commit reaches
the repo at https://github.com/datalad/git-annex/ appveyor should see it
and run.

credit

keyspell ignore tmp directory

keyspell unignore valus

seems clean without this

codespell ignore build artiacts

Add rudimentary .codespellrc with skips I found needed

added some eyeballed skips

Ignores picked up among 3 letter words using helper

    /home/yoh/deb/gits/pkg-exppsy/afni-upstream/.codespell-ignore-shorts.sh 3 | tr '\n' ','

Ignored thanks file

Apply codespell -w throughout

Typo: recurrance -> recurrence

Typo: sansative -> sensitive

Fix ambigous typos

Added a comment

Added a comment: An example of what I see

reproduced

todo that I decided not to do, recorded for posterity

comment

copy --from --to location tracking update

copy: When --from and --to are combined and the content is already present
on the destination remote, update location tracking as necessary.

Sponsored-by: Dartmouth College's DANDI project

one-way escaping of newlines in uuid.log

A repository can have a newline in its description due to being in a
directory containing a newline, or due to git-annex describe being
passed a string with a newline in it for some reason. Putting that
newline in uuid.log breaks its format.

So, escape the newline when it enters uuid.log, to \n

This is a one-way escaping, it is not converted back to a newline
when reading the log. If it were, commands like git-annex info and
whereis would display a multi-line description, which could be confusing
to read.

And, implementing roundtripping would necessarily cause problems if an
old version of git-annex were used to set a description that contained
whatever special character is used to escape the \n. Eg, a \ or if
it used the ! prefix before base64 data that is used in some other logs,
the ! character. Then the description set by the old git-annex would not
roundtrip.

There just doesn't seem to be any benefit of roundtripping newlines through,
so why bother? And, git often displays \n for newline when a filename
contains a newline, so git-annex doing it in this case seems sorta ok
by analogy to git.

(Some other git-annex logs can also have newlines put into them if the
user really wants to break git-annex. For example:
git-annex config annex.largefiles "foo
bar"
The full list is probably config.log, remote.log, group.log,
preferred-content.log, required-content.log,
group-preferred-content.log, schedule.log. Probably there is no
good reason to use a newline in any of these, and the breakage is
probably limited to the bad data the user put in not coming back out.
And users can write any garbage to log files themselves manually in any
case. So, I am not going to address all of those at this time. If a
problem such as this one with the newline in the repository path comes
up, it can be dealt with on a case by case basis.)

Sponsored-by: Dartmouth College's Datalad project

tag datalad

It links to a datalad issue, so I suppose this is right?

make hashFile support paths with newlines

git hash-object --stdin-paths is a newline protocol so it cannot
support them. It would help to not use absPath, when the problem
is that the repository itself is in a path with a newline. But,
there's a reason it used absPath, which is that
git hash-object --stdin-paths actually chdirs to the top of the
repository on startup! That is not documented, and I think is a bug
in git.

I considered making the path relative to the top of the repo, but
then what if this is a git bug and gets fixed? git-annex would break
horribly.

So instead, keep the absPath, but when the path contains a newline,
fall back to running git hash-object once per file, which avoids
the problem with newlines and --stdin-paths. It will be slower,
but this is an edge case. (Similar slow code paths are already used
elsewhere when dealing with filenames with newlines and other parts
of git that use line-based protocols.)

Sponsored-by: Dartmouth College's Datalad project

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

importfeed: Display feed title

When importing a bunch of feeds, this makes it more clear what it's working
on. Also, I sometimes want to delete a particular feed from a list of feeds
but don't know which url belongs to the feed, and this solves that.

Control characters are filtered out just to protect against some feed
putting escape character stuff in the feed, which could be a
security problem. (Control characters also get filtered out of
importfeed filenames.)

Sponsored-by: Luke Shumaker on Patreon

Fix typos "=yet" -> "=yes"

fixed

fix oops

amdd64 vs arm64 confusion

typo

fix links

added arm64-ancient build

Added arm64 build for ancient kernels, needed to support Android phones
whose kernels are too old to support kernels used by the current arm64
build.

Updated Android/git-annex-install to use it. (Also made it use i386-ancient
because that seems like a good idea.)

Sponsored-by: Noam Kremen on Patreon

comment

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

include subdir when checking export branch is checked out

sync: Fix a reversion that prevented sending files to exporttree=yes
remotes when annex-tracking-branch was configured to branch:subdir
(Introduced in version 10.20230214)

Sponsored-by: Kevin Mueller on Patreon

close

Added a comment

original idea on some "native" support for ephemeral datalad clones.

fix OSx build better

comment

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

fix build on OSX

Breakage from 54ad1b4cfb1c8302f1b862cb2699ab9351e3eb5b

remove redundant import

Added a comment

Added a comment

initial report on newlines fiasco

initial report on deficiency of copy --from --to

FTBFS bug report

open bug

comment

comment

re-close with comment

further fix windows build

Thanks to jkniiv for this patch.

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

update

Added a comment

Added a comment: Hello,

Added a comment