Refactor handling of error_string in receive-pack
authorShawn O. Pearce <spearce@spearce.org>
Wed, 7 Mar 2007 21:51:59 +0000 (16:51 -0500)
committerJunio C Hamano <junkio@cox.net>
Wed, 7 Mar 2007 22:47:09 +0000 (14:47 -0800)
commit8aaf7d6410119ee221f5d3ebdc4fc5a57f862665
treeb8360ef8652b0a9c7d2196ca0eca5c9e125d4c76
parentc8dd277109c1cdb9422e474e6bd6e32a382291a0
Refactor handling of error_string in receive-pack

I discovered we did not send an ng line in the report-status feedback
if the ref was not updated because the repository has the config
option receive.denyNonFastForwards enabled.  I think the reason this
happened is that it is simply too easy to forget to set error_string
when returning back a failure from update()

We now return an ng line for a non-fastforward update, which in
turn will cause send-pack to exit with a non-zero exit status.
Hence the modified test.

This refactoring changes update to return a const char* describing
the error, which execute_commands always loads into error_string.
The result is what I think is cleaner code, and allows us to
initialize the error_string member to NULL when we read_head_info.

I want error_string to be NULL in all commands before we call
execute_commands, so that we can reuse the run_hook function to
execute a new pre-receive hook.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
receive-pack.c
t/t5400-send-pack.sh