At the moment the first time a maintainer pushes the nostr remote, it checks for a state announcement and if it can't find one, it creates it based off the state on the first git server listed.
I'll change that so, if the git server responds with a not found error, it creates one containing just the pushed ref(s) so it should work with that flow.
I'm trying this but it's not working.
There are no state events but it is not trying to create any, just pushing.
the repository already exists on the git server?
What do you mean by "exist"? I had never pushed it.
I havn't updated the remote helper yet so that it will push a new state event if one doesn't exist and the git server responds with a not found error (as apposed to timeout).
until I have done that you will need to have the repository on the git server, which it will use as a source for the first state event.
You mean a state event should exist on the server? Or the code should be available on the server? Does git-remote-nostr try to fetch the remote refs before pushing?
Let's suppose a remote state exists on the server, it says the branch "master" points to commit "01010202". Why is that useful if I just want to say "master" now points to "11112222"? Won't it be replaced?
the server should respond to a 'list' request with return the refs.
the remote helper tries to get the refs on the remote server so it can check if there is a conflict.
in git push should only work if its a fast-forward commit unless the `--force` flag is used.
if a state event has been issued (so state is being managed on nostr) the remote helper still checks the refs on the git server(s) to add protections to reduce the likelihood that another maintainer pushes a conflicting change at about the same time which gets overwritten.
Also covering the scenario where there owner or another maintainer starts pushing directly to the git server (by passing the state on nostr). in this case the latest conflicting changes on the git server shouldn't be automatically overwritten without the owner being warned about it.
if 01010202 is in the ancestory of 11112222 then it `git push` will work fine. if it is not, `git push --force` must be used to purposefully overwrite and potentially lose someone else's change. this is standard git.
The git remote helper also check each git server listed to ensure it is not overwriting any ones changes pushed directly to each server as sometimes the state of the git server might differ from the nostr state event.
In fact, if one of the git server(s) is ahead of the git state with conflicting changes, the user maintainer needs to push directly to that git server to overwrite the changes before they can proceed to get everything back in sync by pushing to the nostr remote.
All of this will only happen on the rare occasion that conflicting changes are pushed at about the same time or if some maintainers stop using the nostr remote as the default one.
