Joey Hess [Fri, 31 May 2024 14:28:56 +0000 (10:28 -0400)]
use cabal list-bin
cabal exec will sometimes output other messages to stdout, which
broke the build. It used to be intermittent in CI, now seems to always
happen. Messages are eg "Resolving dependencies..."
It seems that cabal list-bin never does this. I hope.
cabal list-bin is fairly new, needing cabal 3.8, which is only in Debian
testing/unstable. So fall back to cabal exec if it fails.
Joey Hess [Thu, 30 May 2024 16:19:46 +0000 (12:19 -0400)]
git-remote-annex: Support urls like annex::https://example.com/foo-repo
Using the usual url download machinery even allows these urls to need
http basic auth, which is prompted for with git-credential. Which opens
the possibility for urls that contain a secret to be used, eg the cipher
for encryption=shared. Although the user is currently on their own
constructing such an url, I do think it would work.
Limited to httpalso for now, for security reasons. Since both httpalso
(and retrieving this very url) is limited by the usual
annex.security.allowed-ip-addresses configs, it's not possible for an
attacker to make one of these urls that sets up a httpalso url that
opens the garage door. Which is one class of attacks to keep in mind
with this thing.
It seems that there could be either a git-config that allows other types
of special remotes to be set up this way, or special remotes could
indicate when they are safe. I do worry that the git-config would
encourage users to set it without thinking through the security
implications. One remote config might be safe to access this way, but
another config, for one with the same type, might not be. This will need
further thought, and real-world examples to decide what to do.
Joey Hess [Wed, 29 May 2024 16:57:10 +0000 (12:57 -0400)]
run cleanupInitialization in all code paths
This is just a good idea, I think. But it fixes this specific bug:
With buggy git version 2.45.1, git clone from an annex:: url, which has
a git-annex branch in it. Then in the repository, git fetch. That
left .git/annex/objects/ populated with bundles, since it did not clean
up. So later using git-annex failed to autoinit.
Joey Hess [Wed, 29 May 2024 16:07:41 +0000 (12:07 -0400)]
add config-uuid to annex:: url for --sameas remotes
And use it to set annex-config-uuid in git config. This makes
using the origin special remote work after cloning.
Without the added Logs.Remote.configSet, instantiating the remote will
look at the annex-config-uuid's config in the remote log, which will be
empty, and so it will fail to find a special remote.
The added deletion of files in the alternatejournaldir is just to make
100% sure they don't get committed to the git-annex branch. Now that
they contain things that definitely should not be committed.
Joey Hess [Tue, 28 May 2024 20:00:55 +0000 (16:00 -0400)]
fix perms of manifest object
With the directory special remote, manifest objects uploaded by
git-remote-annex were mode 600. This prevented accessing them
from a httpalso special remote, for example.
The directory special remote just copies the file perms. Which is fine
except in this case the file perms were wrong.
Joey Hess [Tue, 28 May 2024 17:26:21 +0000 (13:26 -0400)]
git-remote-annex: brought back max-git-bundles config
An incremental push that gets converted to a full push due to this
config results in the inManifest having just one bundle in it, and the
outManifest listing every other bundle. So it actually takes up more
space on the special remote. But, it speeds up clone and fetch to not
have to download a long series of bundles for incremental pushes.
Joey Hess [Tue, 28 May 2024 16:39:42 +0000 (12:39 -0400)]
adjust unlocked execute bit handling
When building an adjusted unlocked branch, make pointer files executable
when the annex object file is executable.
This slows down git-annex adjust --unlock/--unlock-present by needing to
stat all annex object files in the tree. Probably not a significant
slowdown compared to other work they do, but I have not benchmarked.
I chose to leave git-annex adjust --unlock marked as stable, even though
get or drop of an object file can change whether it would make the pointer
file executable. Partly because making it unstable would slow down
re-adjustment, and partly for symmetry with the handling of an unlocked
pointer file that is executable when the content is dropped, which does not
remove its execute bit.
Joey Hess [Mon, 27 May 2024 17:28:05 +0000 (13:28 -0400)]
git-remote-annex: Fix error display on clone
cleanupInitialization gets run when an exception is thrown, so needs to
avoid throwing exceptions itself, as that would hide the error message
that the user needs to see.
Joey Hess [Mon, 27 May 2024 16:35:42 +0000 (12:35 -0400)]
git-remote-annex: support importrree=yes remotes
When exporttree=yes is also set. Probably it would also be possible to
support ones with only importtree=yes, by enabling exporttree=yes for
the remote only when using git-remote-annex, but let's keep this
simple... I'm not sure what gets recorded in .git/annex/ state
differently in the two cases that might cause a problem when doing that.
Note that the full annex:: urls generated and displayed for such a
remote omit the importree=yes. Which is ok, cloning from such an url
uses an exporttree=remote, but the git-annex branch doesn't get written
by this program, so once the real config is available from the git-annex
branch, it will still function as an importree=yes remote.
Joey Hess [Fri, 24 May 2024 19:49:53 +0000 (15:49 -0400)]
work around git "defense in depth" breakage with git clone checking for hooks
This git bug also broke git-lfs, and I am confident it will be reverted
in the next release.
For now, cloning from an annex:: url wastes some bandwidth on the next
pull by not caching bundles locally.
If git doesn't fix this in the next version, I'd be tempted to rethink
whether bundle objects need to be cached locally. It would be possible to
instead remember which bundles have been seen and their heads, and
respond to the list command with the heads, and avoid unbundling them
agian in fetch. This might even be a useful performance improvement in
the latter case. It would be quite a complication to a currently simple
implementation though.
Joey Hess [Fri, 24 May 2024 19:33:35 +0000 (15:33 -0400)]
convert srcref to a sha
This fixes pushing a new ref that is the same as something already
pushed. In findotherprereq, it compares two shas, which didn't work when
one is actually not a sha but a ref.
This is one of those cases where Sha being an alias for Ref makes it
hard to catch mistakes. One of these days those need to be
differentiated at the type level, but not today..
Joey Hess [Fri, 24 May 2024 18:52:22 +0000 (14:52 -0400)]
sync with special remotes with an annex:: url
Check explicitly for an annex:: url, not just any url. While no built-in
special remotes set an url, except ones that can be synced with, it
seems possible that some external special remote sets an url for its own
use, but did not expect it to be used by git-annex sync et al.
projects / git-annex.git / log