From: Aaron Schrab Date: Sat, 29 Dec 2012 14:50:25 GMT Subject: Re: [PATCH 0/4] pre-push hook support Message-ID: <20121229145025.GA3789@pug.qqx.org> In-Reply-To: <7v1ue9hb06.fsf@alter.siamese.dyndns.org> At 18:01 -0800 28 Dec 2012, Junio C Hamano wrote: >One lesson we learned long time ago while doing hooks is to avoid >unbound number of command line arguments and instead feed them from >the standard input. I think this should do the same. Good point. I had been trying to keep the interface for this hook as close as possible to the ones for other client-side hooks on the theory that less development effort may go into those than for server-side hooks. But thinking on that more I certainly see that this could easily run into limits on argument length on some systems; especially when it's likely that each of those arguments is likely to be over 100 bytes long. I'll work on an updated version which sends the variable length information over a pipe, using the command-line arguments only to pass the remote name and URL. >How does the hook communicate its decision to the calling Git? > >Will it be "all-or-none", or "I'll allow these but not those"? Currently it just uses the exit code to communicate that back, so it's all-or-none. I think I'll keep that in the updated version as well. A future enhancement could modify the protocol to support reading from the hook's stdout the names of remote refs which are to be rejected, I think that just having the option for all-or-nothing is a good starting point.