"push to create" as supported by eg Forgejo makes a git push to a new
git repository create the repository.
Since the repository does not exist when git-annex probes the UUID,
which happens before any push, annex-ignore is set to true.
So a command like git-annex push will do the git push and create the
repository, but fail to discover the uuid of that repository, and so
not send annexed files to it.
forgejo-aneksajo has worked around this by making git-annex's request for "$url/config" create the repository. See:
- https://codeberg.org/forgejo-aneksajo/forgejo-aneksajo/commit/3c53e9803de9c59e9e78ac19f0bb107651bb48f8
- https://codeberg.org/forgejo-aneksajo/forgejo-aneksajo/issues/85
- https://codeberg.org/forgejo-aneksajo/forgejo-aneksajo/issues/83#issuecomment-5093679 and following comments
But that means that git-annex pull will also auto-create the repository.
Or even a command like git-annex info that does UUID discovery of a newly
added remote.
git-annex could support push to create better by having git-annex push,
after pushing the git branches, regenerate the remote list, while
ignoring the annex-ignore configuration of remotes.
So if the branch push created the git repo, any annex uuid that the
new repo has would be discovered at that point. (And at that point annex-ignore
would need to be cleared.)
The remote list regeneration would only need to be done when there are git remotes that don't have a UUID. This would slow down pushes to eg github slightly, since it would ignore annex-ignore being set, and re-probe the git config to see if a UUID has appeared. That seems a small enough price to pay.
The assistant would also need to be made to handle this. --Joey
The annex-ignore config can be manually set by the user to prevent using an otherwise usable remote. The man page gives the example of a network connection that is too slow to use normally.
It may be that no users are actually using annex-ignore like this. Using annex-sync seems more likely. But, it's hard to rule out.
That presents a problem, since this would need to unset annex-ignore once the repository was created.
Checking before push if the repository exists, and only unsetting annex-ignore if it did not exist before sync, but does afterwards, would be one way around this problem. It does mean that, if 2 people are making a repository at the same location at the same time, the loser may be left with annex-ignore set due to the other person having created the repository.
Or, a new config could be added, that is like annex-ignore, but is only set by git-annex, and not by the user. Keeping annex-ignore's behavior, but making git-annex set and unset the new config as needed.
Problem with a new config (call it annex-ignore-auto) is that users may have learned to unset annex-ignore when there was a problem that got corrected, and would need to learn to unset annex-ignore-auto instead. While
git-annex pushwould do it for them, they might not use that.Is this disruptive change worth it to support push-to-create? Probably. But it does make the option of checking before push and after push and unsetting annex-ignore seem more appealing.
The situation where 2 users are doing push to create of the same remote repo at the same time is very unlikely to happen. And currently what happens is that both have to unset annex-ignore. A change that makes only one of them but not the other need to unset it is not making things worse.
Here's a better plan: annex-ignore remains the config, but annex-ignore-auto is set when git-annex sets annex-ignore. If the user manually sets annex-ignore, they don't set annex-ignore-auto.
Then,
git-annex pushcan check if push-to-create happend and unset annex-ignore iff annex-ignore-auto is set.The user might manually
git push, knowing push-to-create is a thing, but do it aftergit-annex init, and so annex-ignore is already set and will stay set until theygit-annex push. Which they may never do.To deal with this, when annex-ignore-auto is set, Remote.Git could check if the remote tracking branch exists. If so, unset annex-ignore-auto and annex-ignore and re-run the uuid probing.