Spencer [Sun, 8 Jun 2025 16:48:06 +0000 (16:48 +0000)]
For one: why would preview show a nonexistent page as an existent link instead of a question mark? For two: why is []() syntax relative to current page but [[|]] syntax is relative to root?
Joey Hess [Wed, 4 Jun 2025 16:06:00 +0000 (12:06 -0400)]
sync: push current branch first
sync: Push the current branch first, rather than a synced branch, to better
support git forges (gitlab, gitea, forgejo, etc.) which use push-to-create
with the first pushed branch becoming the default branch.
With considerable complication to filter out warning message about
receive.denyCurrentBranch when pushing to a non-bare repository. Localization
may break it in the future, but it seems like the best way to handle this. See
my comments for the gory details.
Joey Hess [Tue, 3 Jun 2025 19:01:38 +0000 (15:01 -0400)]
annex.fastcopy
Added annex.fastcopy and remote.name.annex-fastcopy config setting. When
set, this allows the copy_file_range syscall to be used, which can eg allow
for server-side copies on NFS. (For fastest copying, also disable
annex.verify or remote.name.annex-verify.)
This is a simple implementation, that does not handle resuming as well as
it possibly could.
It can be used with both local git remotes (including on NFS), and
directory special remotes. Other types of remotes could in theory also
support it, so I've left the config documented as a general thing.
Joey Hess [Fri, 30 May 2025 17:28:36 +0000 (13:28 -0400)]
add git-remote-tor-annex target
Just for consistency, it makes the symlink for git-remote-annex and
git-annex-shell, but not for git-remote-tor-annex despite that being
another one of the multicall programs.
Joey Hess [Fri, 30 May 2025 17:18:26 +0000 (13:18 -0400)]
moveFile on windows forgot to delete src file in fallback case
This dates back to commit 625303226dc94c2f35a5a4835b7c53c582014643,
where a cross-device moveFile on Windows was made to fall back to copying
to the destination, but forgot to delete the source file.
Should fix the following test suite failure on Windows:
import: FAIL (2.52s)
.\Test\Framework.hs:383:
C:\Users\RUNNER~1\AppData\Local\Temp\importtest.0\import1\f exists unexpectedly
Use -p '/import/' to rerun this test only.
Which was seen here, running the test suite in the github action environment.
https://github.com/psychoinformatics-de/git-annex-wheel/issues/5
Joey Hess [Tue, 27 May 2025 16:49:21 +0000 (12:49 -0400)]
prevent initialization with bad freeze/thaw hook configured
When annex.freezecontent-command or annex.thawcontent-command is configured
but fails, prevent initialization.
This allows the user to fix their configuration and avoid crippled
filesystem detection entering an adjusted unlocked branch unexpectedly,
when they had been relying on the hooks working around their filesystems's
infelicities.
In the case of git-remote-annex, a failure of these hooks is taken to mean
the filesystem may be crippled, so it deletes the bundles objects and
avoids initialization. That might mean extra work, but only in this edge
case where the hook is misconfigured. And it keeps the command working
for cloning even despite the misconfiguration.
Sponsored-by: the NIH-funded NICEMAN (ReproNim TR&D3) project
Joey Hess [Thu, 22 May 2025 16:56:31 +0000 (12:56 -0400)]
assistant: Avoid startup hang on active *.lock file
Avoid hanging at startup when a process has a *.lock file open in the .git
directory.
The goal is to repair stale locks, not wait for all active locks to be
closed. This was causing problems for a non-git process that has its own
lock file in a subdir of .git/.
If .git/index_lock is a non-stale lock, this does let the assistant start
up regardless. Commits by the assistant will then fail, until the process
locking the index finishes. This is not a problem, because the same
behavior could already happen if the assistant is started and then another
process locks the index.
Sponsored-by: the NIH-funded NICEMAN (ReproNim TR&D3) project
projects / git-annex.git / log