Andy Parkins <andyparkins@xxxxxxxxx> writes: > I wanted to delete a branch (let's call it "deleted-branch") from my public > repository. I ran this: > > $ git push origin :deleted-branch > deleting 'refs/heads/deleted-branch' > Also local refs/remotes/up/deleted-branch > *** Update hook: aborting > error: hooks/update exited with error code 1 > error: hook declined to update refs/heads/deleted-branch > ng refs/heads/deleted-branch hook declined > error: failed to push to '/path/to/git/repo.git' > ... > Summary: when using git-push to delete a remote branch, and that deletion is > disallowed by the update hook, the local tracking branch _is_ deleted. Yes, a few months ago with b516968f, "send-pack" started to pretend that it turned around and fetched immediately after it attempted to push. There are two problems with it. One is this exact problem Andy reported. Newer receive-pack reports the status (if an update of the ref was successful), and the sender _could_ try to detect a failure and refrain from making the local side update (but if the receive-pack running on the other end is old enough there is no indication of an error); the code does not bother to do this correctly. I think this is correctable without major changes. If the remote end refused to update only one of the refs, and send-pack as a whole fails, we could refrain from updating anything local. But another more fundamental issue is that post-update hook on the receiving end could do anything it pleases (for example, it could try to rebase what was pushed), and at the protocol level there is no way to say "you tried to push this SHA-1 but we replaced it with this other SHA-1 instead". - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
