removed

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

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

retitle bug report now that it's reopened

reopen bug, 2nd try -- now with backslashes :)

reopen bug -- the fix Joey committed didn't build

Added a comment: ok, that didn't quite resolve it

Added a comment

fix build on OSX

This is built when building Setuo, and after
54ad1b4cfb1c8302f1b862cb2699ab9351e3eb5b, such modules cannot import
Utility.Directory, because it depends on unix, which is not in
setup-depends. This module only needs System.Directory, so import
Utility.SystemDirectory instead.

Sponsored-by: Dartmouth College's Datalad project

fix build on windows

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

report on windows build failure (commit 54ad1b4cf)

small RawFilePath optimisation

comment

Windows: Support long filenames in more (possibly all) of the code

Works around this bug in unix-compat:
https://github.com/jacobstanley/unix-compat/issues/56
getFileStatus and other FilePath using functions in unix-compat do not do
UNC conversion on Windows.

Made Utility.RawFilePath use convertToWindowsNativeNamespace to do the
necessary conversion on windows to support long filenames.

Audited all imports of System.PosixCompat.Files to make sure that no
functions that operate on FilePath were imported from it. Instead, use
the equvilants from Utility.RawFilePath. In particular the
re-export of that module in Common had to be removed, which led to lots
of other changes throughout the code.

The changes to Build.Configure, Build.DesktopFile, and Build.TestConfig
make Utility.Directory not be needed to build setup. And so let it use
Utility.RawFilePath, which depends on unix, which cannot be in
setup-depends.

Sponsored-by: Dartmouth College's Datalad project

avoid using Utility.Path.AbsRel in Utility.Path.Windows

AbsRel depends on unix, but Utility.Path.Windows will be used in some
libraries that are part of the setup-depends, which cannot depend on
unix.

The only reason that AbsRel uses getWorkingDirectory on unix is that
it returns RawFilePath. getCurrentDirectory returns FilePath and so
needs a conversion to RawFilePath. Looks like a newer version of
directory will fix that, by using OsPath, so eventually AbsPath should
be able to switch to using getCurrentDirectory on unix, and then the
small code duplication in this commit won't be needed.

Sponsored-by: Dartmouth College's Datalad project

factor out convertToWindowsNativeNamespace into its own module

Gonna use this more widely.

Sponsored-by: Dartmouth College's Datalad project

comment

close

close

deprecate git-annex status w/o runtime warning

As far as I can see, git-annex status was added to support direct mode, and
like other things added for that, it ought to be deprecated.

Behavior is similar to git status --short, though not identical in a few
cases eg renamed files.

I think datalad does not use this command, although it might have in the
past. Could not find any use of it in the current datalad code.

A deprecation warning at runtime would be the next step, probably will wait
and do that for all the deprecated commands together (except findref).

Added a comment: Update for git-annex 10.20230227-ga206cdddb4

devblog

done with adjusted view branches!

Well, perhaps it could be documented better, but it's a compositional
feature so users who need it will probably try it and be happy to find
that it works.

support git-annex view in an adjusted branch

Rather than entering a view of the adjusted branch, enter an adjusted
view branch. This way, it's the same as first using git-amnnex view
followed by git-annex adjust, and everything already implemented to
support that works.

Sponsored-by: Nicholas Golder-Manning on Patreon

support --hide-missing adjustment of view branches

I had thought this would not make sense to combine with view branches,
since removing files from a view changes metadata.

However, that's committing removal of files. With --hide-missing, the
files get removed when git-annex updates the branch itself, so there is
no conflict.

It does not seem likely to be very useful, but it does work! And that's
nice because it means all types of adjusted branches can be combined with
view branches.

Sponsored-by: Max Thoursie on Patreon

support --unlock-present adjustment of view branches

When generating the view, check if the key is present.

When syncing in a view branch with an adjustment, run adjustedBranchRefreshFull
the same as is done when syncing in other adjusted branches. This is
needed because the docs for git-annex adjust --unlock-present suggest
using git-annex sync to update the branch when annex.adjustedbranchrefresh
is not set.

Note that, with annex.adjustedbranchrefresh set, it just works! The
adjusted branch gets updated in the usual way and it doesn't matter that
there's a view branch underneath.

And of course, re-running git-annex adjut --unlock-present also works,
as suggested in the docs.

Sponsored-by: Erik Bjäreholt on Patreon

support generation of unlocked views

Just make pointer files rather than symlinks, easy.

As for the other adjustments:
--lock is the default for views
--fix happens automatically in views
--hide-missing probably does not make sense when combined with views,
because deleting a file from a view removes metadata
--unlock-present will need a bit more work

rawfilepath conversion

understand adjusted view branch names

An adjusted view branch has a name like
"refs/heads/adjusted/views/master(author=_)(unlocked)", so it is a view
branch that has been converted to an adjusted branch.

Made Logs.View support such branch names. So now git-annex sync and
pre-commit handle updating metadata on commit in such a branch.

Much remains to be done to fully support adjusted view branches,
including actually applying the adjustment when updating the view branch.

Sponsored-by: Graham Spencer on Patreon

overwrite old adjusted view branch

When git-annex adjust is run in a view branch, and the adjusted branch
already exists, overwrite the old adjusted branch with the new one
without being forced.

Usually overwriting an adjusted branch is avoided because it could lose
data. But when a view branch has been adjusted, there is no data to lose
in the adjusted branch, because the only changes that can be made of
significance are to move files between directories. Which changes
metadata on commit. And the old branch has already been committed.

Sponsored-by: Lawrence Brogan on Patreon

improve adjusted branch name parsing to support adjusted view branches

An adjusted view branch has a name like
"adjusted/views/master(author=_)(unlocked)"
and so the adjustment starts at the last open paren, not the first open
paren.

Note that git-annex sync still does not do anything useful when run in
such a branch, because it does not realize that it is a view branch.
This is only groundwork for adjusted view branches.

This also fixes adjusted branches when the basis branch name contains
parens for some other reason, though that is not common in a git branch
name.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

add news item for git-annex 10.20230227

releasing package git-annex version 10.20230227

comment

comment