From: Arun Raghavan Date: Tue, 02 Feb 2010 05:50:16 GMT Subject: Re: [PATCH 0/2] upload-pack: pre- and post- hooks Message-ID: <6f8b45101002012150k784b6d78ibffa5092507eee32@mail.gmail.com> In-Reply-To: <20100201160141.GG8916@spearce.org> On 1 February 2010 21:31, Shawn O. Pearce wrote: > Arun Raghavan wrote: >> On 1 February 2010 20:50, Shawn O. Pearce wrote: >> > Arun Raghavan wrote: [...] >> >> At some point if the future, if needed, this could also be made a part of the >> >> negotiation between the client and server. >> > >> > I'm not sure I follow. >> > >> > Are you proposing the server advertises that it wants to run hooks, >> > and lets the client decide whether or not they should be executed? >> >> Something like that. I was thinking the client could always advertise >> whether the it wants to allow the hooks to be executed or not (which >> would override the default value of the global variable I introduced). >> Either approach would work, though the second is simpler but also >> dumber. >> >> Again, this might be over-complicating things, which is why I did not >> implement it. I just wanted to make a note of the fact that this could >> be done if the need is felt. > > My concern with this is, users might disable the hook all of the > time, and then servers that actually want the hook (e.g. gentoo's > use of the pre-upload-pack to avoid initial clones over git://) > would be stuck, just like they are today. > > No, its just not sane to give the user a choice whether or not they > should execute something remotely. Ah, sorry I wasn't clear about this. I've made it so that when pre-upload-pack fails, the entire operation fails. This makes sense because pre-upload-pack is meant to check things like "do we want allow the user to get the pack". For post-upload-pack, failure only results in a warning, since the actual upload is already done and there's not much to do other than log the failure. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) & (arunsr | GNOME)