git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref

From
Sitaram Chamarty <sitaramc@gmail.com>
Date
Sep 25, 2011, 12:05 UTC
Message-ID
<CAMK1S_h3ufrK29_ajpcSSW7HV6ZA8z8ZVHvhHr2bx5Cga5FAKQ@mail.gmail.com>
In-Reply-To
<20110925094822.GA1702@myhost>
On Sun, Sep 25, 2011 at 3:18 PM, Pang Yan Han <pangyanhan@gmail.com> wrote:
> On Sun, Sep 25, 2011 at 01:28:31PM +0530, Sitaram Chamarty wrote:
[snip]
>> It doesn't make sense to disable only the update hook.  And although I
>> did not come right out and say it, it is the post-update that I care
>> about.  If that still runs, my "issue" still exists.
> Um I'm rather new to Git and the reason why I didn't reply this initially was
> because I didn't know what to reply. Sorry but you sound rather aggressive and
> I was really taken aback by this.
Sorry if I sounded aggressive; I was going to brevity, and levity suffered :-)
[snip lots of stuff about new approach]
> What do you think of this approach (if it's even correct)?

I'm sorry again but it's been almost 2 decades since I did any serious C and I've never dug into git internals, so I can't tell you if you're even on the right track. You should wait for one of the other folks you cc-d to weigh in with their opinions.

Personally, anytime someone says "disable the update hook" I get very worried -- I've got a heck of a lot invested in update hooks ;-)

I wasn't even *asking* about disabling that; I was asking about *post*-update, which you didn't even address in your code.

From a philosophical point of view, update and pre-receive *check* things to make sure everything is OK. IMO they should be allowed to run even if the ref being deleted doesn't exist -- that could well be an error condition that the guy who owns the repo wants to trap and alert himself to in some special way. I would *not* like them disabled.

Post-{update,receive} are for *after* a successful push. My suggestion would be to make sure the inputs supplied to those hooks (via STDIN for post-receive, and as arguments in case of post-update) reflect this -- only successfully updated refs are sent in as args.

This might mean that in the case of 'git push origin :refs/heads/non-existent-ref' the post-receive hook would run but STDIN would be empty, and post-update would run but have no arguments.

That is, IMO, the correct way to deal with this.
Previous: Pang Yan HanNext: Junio C Hamano
Message 10 of 18 in “Teach receive-pack not to run update hook for corrupt/non existent ref”
  1. 0/2 Teach receive-pack not to run update hook for corrupt/non existent refPang Yan Han, Sep 25, 2011
  2. 1/2 is_url: Remove redundant assignmentPang Yan Han, Sep 25, 2011
  3. Tay Ray ChuanSep 25, 2011
  4. Junio C HamanoSep 26, 2011
  5. Jeff KingSep 26, 2011
  6. 2/2 receive-pack: Don't run update hook for corrupt or nonexistent refPang Yan Han, Sep 25, 2011
  7. 2/2 run post-receive and post-update hooks with empty stdin/no args for invalid ref deletionPang Yan Han, Sep 25, 2011
  8. Sitaram ChamartySep 25, 2011
  9. Pang Yan HanSep 25, 2011
  10. Sitaram ChamartySep 25, 2011
  11. Junio C HamanoSep 26, 2011
  12. Sitaram ChamartySep 26, 2011
  13. Junio C HamanoSep 26, 2011
  14. Junio C HamanoSep 27, 2011
  15. Pang Yan HanSep 27, 2011
  16. Junio C HamanoSep 27, 2011
  17. Pang Yan HanSep 27, 2011
  18. Sitaram ChamartySep 27, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.