Recent comments posted to this site:

Thank you! I just tried the mask remote with our forgejo-aneksajo instance with HTTPS push and the mask remote works just as intended. This will be very useful!
Comment by msz Tue Apr 29 17:00:36 2025
If you initialise a remote as private, and then change your mind, is there anyway to promote that remote and it's metadata back to a public scoping?
Comment by beryllium Mon Apr 28 05:53:47 2025

Yup:

❯ git annex info git-annex/linux/current/git-annex-standalone-amd64.tar.gz
file: git-annex/linux/current/git-annex-standalone-amd64.tar.gz
size: 62.24 megabytes
key: SHA256E-s62243866--e127f7cbb28d116cb34a22321b3a8db469d73174b23869c122d9425066729ea5.tar.gz
present: false
❯ git annex whereis git-annex/linux/current/git-annex-standalone-amd64.tar.gz
whereis git-annex/linux/current/git-annex-standalone-amd64.tar.gz (1 copy) 
    4f2108b9-5561-40a1-8923-b0b683b3b898 -- joey@kite:~/lib/downloads
ok
Comment by nobodyinperson Thu Apr 24 15:23:47 2025
https://downloads.kitenet.net/git-annex/linux/current only contains .sig files. so the link above are broken.
Comment by Basile.Pinsard Thu Apr 24 14:27:33 2025

Is there any option/configuration to disable the creation and use of "synced/*" branches on git annex sync?

I have a simple "centralised" setup where local clones push/pull from a single remote bare repository, so I don't see the benefit of using "synced/*" branches. They mostly just add noise in whichever git GUI I use.

Comment by matteo Thu Apr 24 02:34:59 2025

Ok, I added path normalization and that fixed the infinite loop that I saw.

I'm not 100% sure that it fixed the loop you saw though. Please test a daily build.

Comment by joey Tue Apr 22 19:42:40 2025

Put in some fixes which have solved the ".git.git" problem.

Also though I reproduced the infinite loop just now, and it still is a problem after my fixes. I had a repo with a remote foo, accessed over ssh. That remote itself had a local remote with path "../foo.git". And foo.git had a remote with path "../foo"

Resulting in a loop like:

ssh://localhost/~/tmp/foo/../foo.git/../foo/../foo.git/../foo/../foo.git/../foo/..

Making the foo.git's remote have a path like "/home/joey/tmp/foo" avoids the problem.

I think that the fix for this is going to need to involve path normalization. Because this could happen with 2 git repos, that don't have git-annex uuids. So it needs to be able to figure out that "foo/../foo.git" is the same as "foo/../foo.git/../foo/../foo.git"

Comment by joey Tue Apr 22 19:27:43 2025

Adding --json to map would be a useful thing to do.

Conceptually, we have here a directed graph (cyclic) with named edges (remote names) and nodes (repository uuids or urls). Fitting a cyclic graph into json probably needs something not unlike the graphviz output, and also as implemented map doesn't actually build the graph internally.

So I envision a json output something like a list of nodes, where each node has a field for uuid (omitted for non-annex git repos), a field for url, and a field containing a list of its remotes. With each json object in the remotes list having a remote name, a uuid (for annex repos), and an url.

As for how well it might fit the needs of your project, some thoughts:

  • map is able to spider out to remotes of remotes, but that's as far as it can go, since it only queries the git config of remote repositories, and does not run itself recursively on other hosts. Which can only get so far, but is a reasonable limitation for it. Often sshing into a remote host to run map recursively would be blocked for security reasons anyway. With --json output, you could run map on several hosts and combine them easily enough.
  • map does not currently show connections to special remotes, which maybe you would need. This would be easy to do for special remotes of the local repository, but it seems like it would actually be pretty hard to do for special remotes of a remote repository.
Comment by joey Tue Apr 22 17:19:05 2025

That might be hard to implement, since it uses servant to do the http serving and that probably does not have a way to listen to a unix domain socket.

Is this needed any more since p2phttp does support serving multiple repositories?

Comment by joey Mon Apr 21 17:02:34 2025
comment 1 cb67146caf6abb5382c6a4c389b76487
[[!comment format=mdwn username="joey" subject="""comment 1""" date="2025-04-21T16:14:49Z" content=""" Produced what I think is the same bug, or related, though without the looping: map foo (sshing...) [2025-04-21 12:33:47.241024518] (Utility.Process) process [1709431] read: ssh ["localhost","-S",".git/annex/ssh/localhost","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","sh -c 'cd ~ && if ! cd '\"'\"'tmp/foo/../foo.git.git'\"'\"' 2>/dev/null; then cd '\"'\"'tmp/foo/../foo.git.git'\"'\"'.git; fi && git config --null --list'" sh: 1: cd: can't cd to tmp/foo/../foo.git.git.git (sshing...) [2025-04-21 12:33:47.249055766] (Utility.Process) process [1709434] read: ssh ["localhost","-S",".git/annex/ssh/localhost","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","git-annex-shell 'configlist' '/~/tmp/foo/../foo.git.git' '--debug'"] git-annex: failed to read git config of git repository in darkstar on /~/tmp/foo/../foo.git.git; perhaps this repository is not set up correctly or has moved Where foo is a remote accessed via ssh, which happens to be on the same host and parent directory as the repo I ran map in, and itself has a remote named foo that has an url of "../foo.git" One or both problems are caused by `map` using Git.Construct.fromRemotes on the git config that is has gotten by sshing to the remote and listing its config. Git.Construct really is written to operate on local repos, and fromRemotes ends up calling Git.Construct.fromPath, which checks doesDirectoryExist ... locally. That is just not ever going to work correctly and map will need to use something else to get the paths to the remotes. ""]]
Mon Apr 21 16:57:59 2025