From: Arun Raghavan <ford_prefect@gentoo.org>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/2] upload-pack: pre- and post- hooks
Date: Tue, 2 Feb 2010 11:20:16 +0530 [thread overview]
Message-ID: <6f8b45101002012150k784b6d78ibffa5092507eee32@mail.gmail.com> (raw)
In-Reply-To: <20100201160141.GG8916@spearce.org>
On 1 February 2010 21:31, Shawn O. Pearce <spearce@spearce.org> wrote:
> Arun Raghavan <ford_prefect@gentoo.org> wrote:
>> On 1 February 2010 20:50, Shawn O. Pearce <spearce@spearce.org> wrote:
>> > Arun Raghavan <ford_prefect@gentoo.org> 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)
next prev parent reply other threads:[~2010-02-02 5:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-14 18:01 Removal of post-upload-hook Arun Raghavan
2010-01-14 19:36 ` Jeff King
2010-01-14 19:41 ` Shawn O. Pearce
2010-01-14 19:52 ` Arun Raghavan
2010-01-14 20:43 ` Jeff King
2010-01-14 21:06 ` Robin H. Johnson
2010-01-15 14:47 ` Jeff King
2010-01-15 6:12 ` Arun Raghavan
2010-01-15 11:52 ` Ilari Liusvaara
2010-01-15 12:14 ` Arun Raghavan
2010-02-01 8:32 ` [PATCH 0/2] upload-pack: pre- and post- hooks Arun Raghavan
2010-02-01 8:32 ` [PATCH 1/2] upload-pack: Reinstate the post-upload-pack hook Arun Raghavan
2010-02-01 8:32 ` [PATCH 2/2] upload-pack: Add a pre-upload-pack hook Arun Raghavan
2010-02-01 15:20 ` [PATCH 0/2] upload-pack: pre- and post- hooks Shawn O. Pearce
2010-02-01 15:50 ` Arun Raghavan
2010-02-01 16:01 ` Shawn O. Pearce
2010-02-02 5:50 ` Arun Raghavan [this message]
2010-02-01 16:30 ` Nicolas Pitre
2010-02-01 16:36 ` Shawn O. Pearce
2010-02-02 5:52 ` Arun Raghavan
2010-02-02 6:15 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6f8b45101002012150k784b6d78ibffa5092507eee32@mail.gmail.com \
--to=ford_prefect@gentoo.org \
--cc=git@vger.kernel.org \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).