Consume all stdin when rcs_receive short-circuits, to avoid git SIPIPE race. We had a weird problem where, after moving to a new, faster server, "git push" would sometimes fail like this: Unpacking objects: 100% (3/3), done. fatal: The remote end hung up unexpectedly fatal: The remote end hung up unexpectedly What turned out to be going on was that git-receive-pack was dying due to an uncaught SIGPIPE. The SIGPIPE occurred when it tried to write to the pre-receive hook's stdin. The pre-receive hook, in this case, was able to do all the checks it needed to do without the input, and so did exit(0) without consuming it. Apparently that causes a race. Most of the time, git forks the hook, writes output to the hook, and then the hook runs, ignores it, and exits. But sometimes, on our new faster server, git forked the hook, and it ran, and exited, before git got around to writing to it, resulting in the SIGPIPE. write(7, "c9f98c67d70a1cfeba382ec27d87644a"..., 100) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) @ 0 (0) --- I think git should ignore SIGPIPE when writing to hooks. Otherwise, hooks may have to go out of their way to consume all input, and as I've seen, the races when they fail to do this can lurk undiscovered. I have written to the git mailing list about this. As a workaround, consume all stdin before exiting.
Fix typo that broke anonymous git push.
refactor check_canchange into IkiWiki library
remove debugging dumper code
indentation and layout
Complete rcs_preprevert and lightly test.
revert check_canedit nosubs thing Abstraction violation. I now think the problem should be treated as a bug in httpauth.
correct logic on error fallthrough
Receive: avoid hiding check_canedit error messages Avoid the generic "you are not allowed to change" message, and instead allow check_canedit to propigate out useful error messages. Went back to calling check_canedit in fatal mode, but added a parameter to avoid calling the troublesome subs that might cause a login attempt.
minor typo
add explicit check_canedit calls when checking canattach or canremove
Avoid trying to log the user in when receiving anonymous pushes from git and a plugin like httpauth returns a login function. Just use check_canedit in nonfatal mode.
remove obsolete check to see if check_canedit is available The function moved from the editpage plugin into IkiWiki core some time ago.
stop using REMOTE_ADDR Everywhere that REMOTE_ADDR was used, a session object is available, so instead use its remote_addr method. In IkiWiki::Receive, stop setting a dummy REMOTE_ADDR. Note that it's possible for a session cookie to be obtained using one IP address, and then used from another IP. In this case, the first IP will now be used. I think that should be ok.
unfinished file_prune revamp Many calls to file_prune were incorrectly calling it with 2 parameters. In cases where the filename being checked is relative to the srcdir, that is not needed. Made absolute filenames be pruned. (This won't work for the 2 parameter call style.)
Merge branch 'master' into cvs
clean up use of IkiWiki::Receive Loading and use of IkiWiki::Receive can all be pushed into the git plugin, rather than scattered around. I had at first wanted to make a receive plugin and move it there, but a plugin was not a good fit; you don't want users to have to manually load it, and making the git plugin load the receive plugin at the right times would need more, and ugly code.
typo
Coding style change: Remove explcit vim folding markers.
move untrusted committer test into the wrapper This saves around 1/4th second per trusted commit since ikiwiki doesn't need to start up.