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

Added a comment: Re: Weird behavior of git archive in combination with largefiles configuration

Added a comment

Added a comment

Improve error message when unable to read a sqlite database due to permissions problem

Old message was:

sqlite query crashed: thread blocked indefinitely in an MVar operation

New message is eg:

sqlite worker thread crashed: SQLite3 returned ErrorCan'tOpen while attempting to perform open ".git/annex/keysdb/db".

The worker thread used to throw an exception. But before that
exception was seen by anything waiting on the worker thread to
finish, the takeMVar in queryDb would have crashed with
BlockedIndefinitelyOnMVar.

Sponsored-by: k0ld on Patreon

comment

comment

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

add m68k to arch lists for webapp build deps

move webapp build deps under Assistant build flag

git-annex.cabal: Move webapp build deps under the Assistant build flag so
git-annex can be built again without yesod etc installed.

Commit 78440ca37d75039d5eadd52eafbcd1751daba70a got rid of the webapp build
flag to work around what was apparently a cabal bug. It moved the webapp
build deps to the main build-depends list. But that prevents building
git-annex when yesod etc are not installed.

Putting them under the Assistant build flag seems to not tickle that cabal
bug, and lets git-annex build automatically with the assistant disabled
when the webapp build deps are not installed.

I hypotehesize that the problem may have involved build-depends nested
behind two build flags. Also, cabal clean may need to be run in order
for cabal to find the right solution after this change, when building in
a directory where cabal configure had been run before.

Also moved 3 modules that are needed to build git-annex w/o the assistant
out from under the Assistant build flag.

Sponsored-by: Brock Spratlen on Patreon

Added a comment

Added a comment

comment

Revert "stack.yaml: Update to lts-19.33 and aws-0.24"

This reverts commit 648e59cac2ea9ab6ea4b6cbc50ab30b34e4938b1.

Failed to build on windows, because

       In the dependencies for haskeline-0.8.2:
           Win32-2.11.1.0 from Stack configuration does not match >=2.1 && <2.10 || >=2.12 (latest
                          matching version is 2.13.4.0)

jkniiv did find a solution that builds:

-- Win32-2.11.1.0
+- Win32-2.9.0.0
+- Cabal-3.6.3.0
+- directory-1.3.7.1
+- process-1.6.17.0
+- time-1.11.1.2

But that is a quite old version of Win32 and risks bugs from it, and bumping
Cabal and directory to newer than lts-19.33 has seems also likely to be risky.

So, I've given up. aws-0.24 won't be able to be in the stack build until
there's a stackage lts (or nightly) that has filepath (>=1.4.100.0),
which will not happen until sometime after the next ghc release.

response

comment and close

comment

fix reversion in info, and add test case

info: Fix reversion in last release involving handling of unsupported input
by continuing to handle any other inputs, before exiting nonzero at the
end.

Sponsored-by: Dartmouth College's Datalad project

Added a comment

duplicating report here to possibly expedite resolution

Added a comment: Weird behavior of git archive in combination with largefiles configuration

removed

Added a comment: Weird behavior of git archive in combination with largefiles configuration

removed

Added a comment: Weird behavior of git archive in combination with largefiles configuration

Added a comment

report on resolver LTS 19 still (!) causing trouble with Win32 for stack builds

fix view reversion caused by optimisation

view: Fix a reversion in 10.20230214 that omitted a file from a view when
the file had no metadata set, but the view only used path fields.

Sponsored-by: Jack Hill on Patreon

close bug as dup and update todo item with implementation plan

a todo on: explicit metadata needed for view inclusion or not

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

stack.yaml: Update to lts-19.33 and aws-0.24

This enables some new features that need the new aws.

Win32 downgraded from the version in lts-19.33 because git-annex does not build
with that version, and newer versions of Win32 need a newer filepath version,
which can't be upgraded while using lts-19.33.

Sponsored-By: Brett Eisenberg on Patreon

close bug as submitter cannot reproduce it

report on sync not working properly with view branches on top of adjusted branches

Fix typo "intiremote"

Added a comment

Revert "revert recent bug fix temporarily for release"

This reverts commit 16f1e2466595da27a56c1a67846ba68a9692b365.

add news item for git-annex 10.20230214

releasing package git-annex version 10.20230214

revert recent bug fix temporarily for release

Decided this bug is not severe enough to delay the release until
tomorrow, so this will be re-applied after the release.

Avoid Git.Config.updateLocation adding "/.git" to the end of the repo
path to a bare repo when git config is not allowed to list the configs
due to the CVE-2022-24765 fix.

That resulted in a confusing error message, and prevented the nice
message that explains how to mark the repo as safe to use.

Made isBare a tristate so that the case where core.bare is not returned can
be handled.

The handling in updateLocation is to check if the directory
contains config and objects and if so assume it's bare.
Note that if that heuristic is somehow wrong, it would construct a repo
that thinks it's bare but is not. That could cause follow-on problems,
but since git-annex then checks checkRepoConfigInaccessible, and skips
using the repo anyway, a wrong guess should not be a problem.

Sponsored-by: Luke Shumaker on Patreon

use isBareRepo

The advantage over Git.Config.isBare is that it avoids a string
comparison and a map lookup.

Sponsored-by: Noam Kremen on Patreon

analysis

fix comment

upper case start of warning

add space after colon in warning message

bug report from forum

comment

Added a comment: 👍 This made it easier for the Thunar plugin!

Added a comment: Resolved

better handling of multiple repositories with the same name

Used to fail with a bad error message, indicating there was no
repository with the specified name, or something like that. Now, suggest
they use the uuid to disambiguate.

* info, enableremotemote, renameremote: Avoid a confusing message when more
  than one repository matches the user provided name.
* info: Exit nonzero when the input is not supported.

Sponsored-by: Kevin Mueller on Patreon

Sped up view branch construction by 50%

A benchmark in my sound repository with `git-annex view feedtitle=*`
took 2:52 wall clock time before and 1:58 after. Though it still only used
130% of CPU.

This is the same kind of optimisation that is in seekFilteredKeys, though
that precaches location logs while this streams the metadata logs direct
to parsing them.

seekFilteredKeys contains more streaming, to find the annexed files, and
this could be further sped up with similar streaming.

Sponsored-by: Nicholas Golder-Manning on Patreon

Added a comment

Added a comment: Have a look at mount options

Added a comment

Added a comment

move a paragraph into the pages that the links it talks about were long ago moved to

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

add warning about Go's past and future data collection

Based on https://github.com/golang/go/discussions/58409, the Go compiler
already defaults to using a google proxy server, which would allow
Google to collect information about what dependencies users are
installing. (Of course they claim they won't.) Two separate environment
settings are needed to turn that off, and users in that thread were
surprised to learn about one of them.

So this warning is already appropriate to some extent.

Also based on the minimisation of user concerns by the golang developers
on that issue and elsewhere, it seems best to assume that they are not
going to be dissuaded from increasing data collection efforts in the future,
even if the blowback prevents this particular attempt.

So this warning should not be removed unless the Go community somehow
extricates itself from Google's control. Or unless ipfs is rewritten in
another language.

Some distros do have ipfs. Unfortunately, Debian appears to be structurally
incapable of packaging it. (8 years and counting;
https://bugs.debian.org/779893). So lots of users will be stuck
installing it from source or having to trust its official binaries.

add a warning about homebrew's use of analytics by default

It apparently displays a notice on first use, but I was surprised to
learn about this behavior today, and I've used it. Displaying a notice
does not make violating users' privacy acceptable.

remove warning about ipfs being alpha code

That may have been true in 2015, but seems very unlikely
to be true now.

close todo and open new one