startExternalAddonProcess add parameters

Not used yet but intended to support eg running "rclone gitannex"

typo fix

comment

todo

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

multiple -m second try

Test suite passes this time. When committing the adjusted branch, use
the old method to make a message that old git-annex can consume. Also
made the code accept the new message, so that eventually
commitTreeExactMessage can be removed.

Sponsored-by: Kevin Mueller on Patreon

Added a comment: Update after transferring more files

Added a comment: or use numcopies for safety

Added a comment: when someone names files like keys, they probably want trouble 🙃

comment

repot MacOS disk usage bug

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

update

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

project we started at Distribits

Added a comment: more use cases for configurable default preferred content

Added a comment

Added a comment: Possible simplified scenario

Add link to English re-recording of Yann's git-annex workshop kickoff talk @Tübix2023

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

mention reversion

Revert "multiple -m"

This reverts commit cee12f6a2fd7f90eb2aa72cd638b6bcdf45e4f92.

This commit broke git-annex init run in a repo that was cloned from a
repo with an adjusted branch checked out.

The problem is that findAdjustingCommit was not able to identify the
commit that created the adjusted branch. It seems that there is an extra
"\n" at the end of the commit message that it does not expect.

Since backwards compatability needs to be maintained, cannot just make
findAdjustingCommit accept it with the "\n". Will have to instead
have one commitTree variant that uses the old method, and use it for
adjusted branch committing.

Added a comment: support for bulk write/read/test remote

Added a comment

Added a comment

fixes

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

multiple -m

sync, assist, import: Allow -m option to be specified multiple times, to
provide additional paragraphs for the commit message.

The option parser didn't allow multiple -m before, so there is no risk of
behavior change breaking something that was for some reason using multiple
-m already.

Pass through to git commands, so that the method used to assemble the
paragrahs is whatever git does. Which might conceivably change in the
future.

Note that git commit-tree has supported -m since git 1.7.7. commitTree
was probably not using it since it predates that version. Since the
configure script prevents building git-annex with git older than 2.1,
there is no risk that it's not supported now.

Sponsored-by: Nicholas Golder-Manning on Patreon

fix typo

Added a comment

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

todo

Added a comment

fix build warning

A recent change made plumbing the backend through fsck unncessary.

Left fsck checking backend and skipping operating on key when it could
not find one. Not checking the backend would be a behavior change.
For example the command git-annex fsck --key FOO--bar does nothing
since FOO is not a known backend. If this were removed it would
instead go on and fsck it and warn that no copies exist of the key.
That behavior change seems like it would be fine, but I also have no
reason to make it.

avoid build warning on windows

windows build fix

comment

update for new rclone gitannex command

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

avoid build warning on windows

Since append was only exported by Annex.Common on unix, excluding it
from import caused a build warning on windows.

fix build on windows

deletestale renamed from cleanstale

fix build warnings on windows

Windows: Fix escaping output to terminal when using old versions of MinTTY

clean up windows build warnings about unused imports

Added a comment

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

link to commit

fix transfer lock file for Download to not include uuid

While redundant concurrent transfers were already prevented in most
cases, it failed to prevent the case where two different repositories were
sending the same content to the same repository. By removing the uuid
from the transfer lock file for Download transfers, one repository
sending content will block the other one from also sending the same
content.

In order to interoperate with old git-annex, the old lock file is still
locked, as well as locking the new one. That added a lot of extra code
and work, and the plan is to eventually stop locking the old lock file,
at some point in time when an old git-annex process is unlikely to be
running at the same time.

Note that in the case of 2 repositories both doing eg
`git-annex copy foo --to origin`
the output is not that great:

copy b (to origin...)
  transfer already in progress, or unable to take transfer lock
git-annex: transfer already in progress, or unable to take transfer lock
97%   966.81 MiB      534 GiB/s 0sp2pstdio: 1 failed

  Lost connection (fd:14: hPutBuf: resource vanished (Broken pipe))

  Transfer failed

Perhaps that output could be cleaned up? Anyway, it's a lot better than letting
the redundant transfer happen and then failing with an obscure error about
a temp file, which is what it did before. And it seems users don't often
try to do this, since nobody ever reported this bug to me before.
(The "97%" there is actually how far along the *other* transfer is.)

Sponsored-by: Joshua Antonishen on Patreon

fix windows transfer lock check

If the lock file was not able to be exclusivlely locked, don't indicate
locking failed. I'm pretty sure this was a typo. It goes all the way
back to 891c85cd88c5a90daf7d18160eeddd1483e8c649 where locking was first
introduced on windows, and there's no indication of why it would make
sense to return True here.

Sponsored-by: Leon Schuermann on Patreon

Add news of git-annex merch from hellotux.com

Add link to hellotux.com git-annex shirts

bug

comment

comment

fix name of option

policy on AI generated content

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

fix reversion in unexport when unable to rename

Bug introduced in commit 7cef5e8f35d211f09eee0af5f8ea0bf689a1d012

update

Added a comment: Need for git-annex-remote-rclone

update

update

link

fix spelling

todo

update

update

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

todo

thoughts

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

comment

fix build warning

A recent change made plumbing the backend through fsck unncessary.

Left fsck checking backend and skipping operating on key when it could
not find one, although I'm not sure if that's necessary to support eg,
keys with unknown backend.

export tree: avoid confusing output about renaming files

When a file in the export is renamed, and the remote's renameExport
returned Nothing, renaming to the temp file would first say it was
renaming, and appear to succeed, but actually what it did was delete the
file. Then renaming from the temp file would not do anything, since the
temp file is not present on the remote. This appeared as if a file got
renamed to a temp file and left there.

Note that exporttree=yes importree=yes remotes have their usual
renameExport replaced with one that returns Nothing. (For reasons
explained in Remote.Helper.ExportImport.) So this happened
even with remotes that support renameExport.

Fix by letting renameExport = Nothing when it's not supported at all.
This avoids displaying the rename.

Sponsored-by: Graham Spencer on Patreon

fix comment

update

fix comment

update

fix indent for readability

attribution armoring

Added a comment: TLS v1.2 EMS (Extended Master/Main Secret)

Added a comment

Added a comment: Still experimental?

add reregisterurl command

What this can currently be used for is only to change an url from being
used by a special remote to being used by the web remote.

This could have been a --move-from option to registerurl. But, that would
have complicated its option and --batch processing, and also would have
complicated unregisterurl, which is implemented on top of
Command.Registerurl. So, a separate command was actually less complicated
to implement.

The generic description of the command is because I want to make this
command a catch-all for other url updating kind of things, if there are
ever any more. Also because it was hard to come up with a good name for the
specific action. I considered `git-annex moveurl`, but that seems to
indicate data is perhaps actually being moved, and seems to sit at the same
level as addurl and rmurl, and this command is at the plumbing
level of registerurl and unregisterurl.

Sponsored-by: Dartmouth College's DANDI project

small problem

comment

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

add todo for tracking free space in repos via git-annex branch

For balanced preferred content perhaps, or just for git-annex info
display.

Sponsored-by: unqueued on Patreon

update

Added a comment

response

comment