Recent comments posted to this site:
- Remove comment
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
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.
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.
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"
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 thegit 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 runmap
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.
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?