Removed support for git versions older than 2.5.

This entirely removes Git.BuildVersion, which avoids the possibility that
git-annex will behave differently based on the version of git it was built
with, rather than the version it's used with.

Debian oldoldstable is the oldest version of git that git-annex needs to
support, since it's used in the amd64ancient build.

cabal configure will fail if the git version is too old.

Sponsored-by: Nicholas Golder-Manning

onlyencryptcreds=yes

initremote: When onlyencryptcreds=yes is used along with embedcreds=yes,
and encryption is enabled, only encrypt the embedded creds, without
encrypting the content of the special remote.

Useful for exporttree=yes/importtree=yes remotes.

Sponsored-by: Joshua Antonishen

bug

bug

remove now unused parameters

comment

fixed

improve error when unable to reverse adjust merge

Give the user a hint about what to do, as well as what they should have
done to avoid the problem.

error out when another branch has been manually merged into the adjusted branch

This avoids losing the merge commit when re-running git-annex adjust in the
adjusted branch.

It also makes git-annex sync error out, rather than displaying a warning
and exiting successfully.

Sponsored-by: Leon Schuermann on Patreon

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

Added a comment: Reproduce Issue

Added a comment: encryption=credsonly

bug

update

warn and refuse to autoenable a special remote when name is in use

Improve behavior when there are special remotes configured with
autoenable=yes with names that conflict with other remotes.

The use of remoteList' is to avoid using the cached remote list in the case
where there are two special remotes both configured to autoenable and both
with the same name. Once the 1st is autoenabled, this makes reload the
remote list and so see the 1st, and so refuse to autoenable the second.

This adds a little bit of overhead, but it should be sufficiently small not
to need optimising.

Sponsored-by: Dartmouth College's OpenNeuro project

followup

close

simplify

info: Added --show option

To pick which parts of the info to calculate and display.

Sponsored-by: Dartmouth College's DANDI project

comment

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

close

Bump aws build dependency to 0.24.1

That's the version in Debian stable now. And this removes a lot of ifdefs.

Also I'm pretty sure a recent commit broke building with older versions of
aws, although that could be fixed with sufficent testing.

probe AWS datacenter

S3: When initremote is given the name of a bucket that already exists,
automatically set datacenter to the right value, rather than needing it to
be explicitly set.

This needs aws-0.23. But, initremote stores the datacenter value, so
a remote set up this way can be used with git-annex built with an older aws.

This is not done when signature=anonymous, because in that case,
using AWS.defaultRegion works fine for accessing buckets on other
datacenters.

It feels a bit round-about to need to do this probing. But without it,
the problem seems to be that, with a v4 signature, the location constraint
is included in the Authorization header. When that is the wrong location,
AWS S3 rejects it. I do wonder though if there is an easier way that I
am currently missing.

Sponsored-by: Dartmouth College's DANDI project

fix default region reversion

Commit 215640096f6a3469c119d50373f3035cf19fe130 caused the default
region for S3 to change to us-east-2. This was due to regionInfo having
an undocumented property that the first item in the list is for the
default region.

Avoid relying on regionInfo for defaultRegion.

Sponsored-by: Dartmouth College's DANDI project

wishlist of faster/specific info for a remote

S3: Default to signature=v4 when using an AWS endpoint

* S3: Default to signature=v4 when using an AWS endpoint, since some
  AWS regions need v4 and all support it. When host= is used to specify
  a different S3 host, the default remains signature=v2.
* webapp: Support setting up S3 buckets in regions that need v4
  signatures.

For the webapp, went ahead and added all current S3 regions
(except govcloud, which  is not usable by everyone).

Sponsored-by: Dartmouth College's DANDI project

document "anonymous" in ValueDesc

comment

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

add https://pypi.org/project/git-annex-remote-internxt/

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

Added a comment: repodata is empty again :(

stack.yaml: Update to lts-24.2.

Add YouTube link

Updated the S3-special-remote example and prose based on recent B2 experience

comment

reword

link to new page

add section on security

inline didn't work due to extension

layout

add example git-annex-p2p-unix-sockets program and end-user docs

improve AuthToken display in P2P --debug

Using an empty string to obscure the AuthToken made it impossible to
tell if one was really being presented or not.

Merge branch 'master' into genericp2p

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

update design doc with changes from genericp2p branch

That branch is basically ready to merge, but needs more testing in a
chicken and egg situation.

Added a comment

avoid broken pipe zombies

hClose crashes if the pipe is broken, preventing waiting for the process

remotedaemon support for generic P2P transports

RemoteDaemon.Transport.Tor was refactored into this, and most of the
code is reused between them.

getSocketFile does not yet deal with repositories on crippled
filesystems that don't support sockets. Annex.Ssh detects that and
allows the user to set an environment variable, and something similar
could be done here.

And it does not deal with a situation where there is no path to the
socket file that is not too long. In that situation it would crash out
I suppose. Probably though, remotedaemon is ran from the top of the
repo, and in that case the path is just ".git/annex/p2p/<md5>" so nice
and short.

This seems to mostly work. But I don't yet have a working git-annex-p2p-
command to test it with.

And with my not quite working git-annex-p2p-foo test script, running
remotedaemon results in an ever-growing number of zombie processes
that it's not waiting on.

changed design for p2p generic socket

Having the git-annex-p2p-<netname> command output the socket filename
left git-annex scrambling to listen to it in order to not miss incoming
connections. And if the command uses something like socat UNIX-CONNECT,
that expects the socket to be accepting connections and errors out when
it's not, that would be a problem.

Rather than complicating the protocol with git-annex needing to send
back a message when it's listening to the socket, simplified it by
having git-annex provide the socket path to the command.

This does mean that, if a P2P network has its own place it expects to
find a socket file, the git-annex-p2p-<netname> command would need to
somehow arrange for it to use the git-annex socket path. A symlink would
be one way to handle that situation.

Add yann's TdF talk about life in git annex

add git-remote-p2p-annex

Added git-remote-p2p-annex, which allows git pull and push to P2P networks
provided by external commands.

This is a refactor of git-remote-tor-annex, and should just work. Except
possibly for quirks with the address parsing. I've checked that the address
parsing basically works.

One thing I don't understand is why git-remote-tor-annex removes "/*" from
the end of the address. The git history does not provide any hints. So I
didn't make git-remote-p2p-annex do the same. Maybe that is needed in some
situation? But, a P2P address could contain "/", so removing it would be a
problem. I can't see anything in gitremote-helpers(7) about why the url
might get such a thing added to the end of it. My guess is that is not
needed for tor either (but does no harm there since onion addresses never
contain "/").

At this point, the implementation of generic P2P transports needs only
remotedaemon support.

use Annex.ExternalAddonProcess for P2P.Generic processes

These are another sort of external addon process, and this makes several
things work including shell scripts on windows. And it makes for nicer
error messages when the command is not in the path.

Note that the refactored startExternalAddonProcess used by this
does not use propGitEnv to set git environment variables in the
environment. Unlike startExternalAddonProcessProtocol which does.
This is because it runs in IO and does not have access to that
information. But also, I don't think that P2P.Generic processes need
that.

p2p --enable

p2p: Added --enable option, which can be used to enable P2P networks
provided by external commands git-annex-p2p-<netname>

Made git-annex p2p --enable tor behave the same as git-annex enable-tor,
to make tor a bit less of a special case. However, it canot be run as root,
since it cannot take the user id parameter.

support P2PAnnex in connectPeer

This is probably enough to support accessing remotes using p2p-annex:: urls.
Not tested yet of course since there is not yet support for serving the
other side of such a connection, or for setting up such a connection.

P2P.Generic has an implementation of the whole interface to the
git-annex-p2p-<netname> commands.

add connProcess to P2PConnection

When using the new generic P2P transport to open an outgoing connection
to a peer, this will hold the pid of the git-annex-p2p-<netname>
command.

closeConnection simply waits for it. Rather than relying on garbage
collection of the closed handles to close it.

In Remote.Helper.Ssh, connProcess is set to Nothing, even though there
is a similar process being used there. That code stores the pid in
OpenConnection instead, and handles waiting for it itself. A bit ugly,
but not worth cleaning up at this point, maybe later.

Added a comment: Use an older version e.g. from archive.org

add P2PAnnex constructor

This is for p2p-annex:: urls that will use the new generic P2P
transport.

In addressCredsFile, threw in an url encoding of any non-alphanumeric
characters that are in the address. This is to avoid any possible path
traversal attacks via a p2p-annex:: url, since the address part of it
could contain any characters. And, went ahead and did the same url
encoding of tor-annex:: urls, even though tor onion addresses are all
alphanumerics, on the off chance that might avoid a similar problem.
(It does not seem likely enough to treat it as a security hole.)

Added a comment: Cataline build missing

document output as a single line

rename design page

documentation for generic P2P transports

design for p2p socket transport

Added a comment: fsck can do this

add news item for git-annex 10.20250721

releasing package git-annex version 10.20250721

Added a comment: Works!

prep for release of 10.20250721

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

Added a comment: Workaround for default wanted content?

run reconcileStaged even in smudge clean filter, using alternate code path

Improved workaround for git 2.50 bug, avoding an occasional test suite
failure, as well as some situations where an unlocked file did not get
populated when adding another file to the repository with the same content.

This uses the alternate code path that was already using when there was
a conflict. Since that code path is not able to record its work,
it will redo the same work next time. If the only way reconcileStaged
is getting run is via the smudge clean filter, that could result in
more and more changes getting processed redundantly each time. Once
some other git-annex command runs and calls reconcileStaged, it
will stop redoing that work. I don't think the extra work will be a
problem.

make --keep-failures show full path to test repo

Otherwise, had to guess which of several subdirectories was the right
one.

fixed build failure

fix build with OsPath build flag

fix build warning

response

Add --url option and url= preferred content expression

To match content that is recorded as present in an url.

Note that, this cannot ask remotes to provide an url using whereisKey, like
whereis does. Because preferred content expressions need to match the same
from multiple perspectives, and the remote would not always be available.

That's why the docs say "recorded as present", but still this may be
surprising to some who see an url in whereis output and are surprised they
cannot match on it.

The use of getDownloader is to strip the downloader prefix from urls like
"yt:". Note that, when OtherDownloader is used, this strips the ":" prefix,
and allows matching on those urls too.

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

todo

Added a comment

todo

Added a comment: fs type?

Added a comment: Thanks!

fsck: Fix location of annexed files when run in linked worktrees

This cleans up after the bug that was fixed in commit
6a9e923c74a1ae5c4c904e7a28e9339bdc241427
Object files that were stored in the wrong location are rescued,
and after that any wrong location logs will be fixed by the usual fsck.

tag INM7

Based on submitter, I assume so..

extend gitAnnexLink special case for worktrees

Fix symlinks generated to annexed content when in adjusted unlocked branch in a
linked worktree on a filesystem not supporting symlinks.

Before this fix, the symlink generated by eg git-annex sync in an adjusted
unlocked branch contained ".git/worktrees/". There was a special case
for the similar problem with submodules, so just use it to handle this case as
well. To detect this case, rely on fixupUnusualRepos setting mainWorkTreePath.

avoid changing gitdir

This code dates back 10 years to commit
e322826e33ede47a2d9c5f979fd629627bcd709c. But as far as I can tell,
it was never necessary. Notice that the comment added in that
commit doesn't match the code -- it says it adjusts the Repo when
the filesystem doesn't support symlinks, but it actually only adjusts
the Repo when the filesystem *does* support symlinks.

Testing in a submodule after this change, annex symlinks still point to
.git/annex/objects/.

(Note that gitAnnexLink contains a special case for submodules on filesystem
not supporting symlinks. I have verified that special case still works.
Without that special case, the annex links look like eg
"../.git/modules/foo/annex/objects", and with them, they look like
".git/annex/objects"

fixed but not ready to close yet

fix handling of linked worktrees on filesystems w/o symlinks

Fix bug in handling of linked worktrees on filesystems not supporting
symlinks, that caused annexed file content to be stored in the wrong
location inside the git directory, and also caused pointer files to not get
populated.

This parameterizes functions in Annex.Locations with a GitLocationMaker.
The uses of standardGitLocationMaker are in cases where the path returned
by a function should not change when in a linked worktree. For example,
gitAnnexLink uses standardGitLocationMaker because symlink targets should
always be to ".git/annex/objects" paths, even when in a linked worktree.
Hopefully I have gotten all uses of standardGitLocationMaker right.

This also assumes that all path construction to the annex directory
is done via the functions in Annex.Locations, and there is no other,
ad-hoc construction elsewhere. Thankfully, Annex.Locations has been around
since the beginning, and has been used consistently. I think.

---

In fixupUnusualRepos, when symlinks are supported, the .git file is replaced
with a symlink to the linked worktree git directory. And in that directory,
an "annex" symlink points to the main annex directory. In that case,
it's not necessary to set mainWorkTreePath. It would be ok to set it,
but not setting it in that case allows an optimisation of avoiding reading
the "commondir" file.

The change to make fixupUnusualRepos set mainWorkTreePath when the
repository is not initialized yet is done in case the initialization itself
writes to the annex directory. If that were the case, without setting
mainWorkTreePath, the annex symlink would not be set up yet, and so
it might have created the annex directory in the wrong place. Currently
that didn't happen, but now that mainWorkTreePath is available, using it
here avoids any such later problem.

---

This commit does not deal with the mess of a worktree that has
experienced this bug before. In particular, if `git-annex get` were
run in such a worktree, it would have stored the object files in the
linked worktree's git directory, rather than in the main git directory.
Such misplaced object files need to be dealt with; the plan is to make
git-annex fsck notice and fix them.

A worktree that has experienced this bug before will contain unpopulated
pointer files. Those may eventually get fixed up in regular usage of
git-annex, but git-annex fsck will also fix them up.

---

Finally, this has me pondering if all of git-annex's state files should
really be stored in one common place across all linked worktrees. Should
perhaps state files that are specific to the worktree be stored per-worktree?
That has not been the case when using git-annex on filesystems supporting
symlinks, but it *has* been the case on filesystems not supporting
symlinks. Perhaps this leads to some other buggy behavior in some cases.
Or perhaps to extra work being done.

For example, the keys database has an associated files table. Which depends
on the worktree. But reconcileStaged updates that table, so when git-annex
is used first in one worktree and then in another one, reconcileStaged will
update the table to reflect the current worktree. Which is extra work each
time a different worktree is used. But also, what if two git-annex
processes are running at the same time, in separate worktrees? Probably
this needs more thought and investigation.

So there is a risk that this commit exposes such buggy behavior in a
situation where it didn't happen before, due to the filesystem not
supporting symlinks. But, given how much this bug crippled using linked
worktrees in such a situation, I doubt that many people have been doing
that.

comment typo

subtlety

complication

analysis

update

another case

reproed

Added a comment