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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Sitaram Chamarty <sitaramc@xxxxxxxxx> writes:
>
>>> In that case (if "non-existent-ref" was indeed non-existent, and not just
>>> pointing at a dangling commit), I would say the post anything hook should
>>> not be called for that ref. These hooks of course need to run if there
>>> are _other_ refs that were updated, though, to handle these _other_ refs,
>>> but I do not think they should be told about the no-op.
>>
>> Question is what happens if none of them existed.  It's a difference
>> between not calling the hook at all, versus calling it with no
>> arguments/empty stdin (as the case may be) -- which would you do?
>
> In case it was unclear, I was trying to say the hooks should not run with
> empty input.

If the purpose of "post-update" (or "post-receive") hooks were to trigger
every time anybody attempted to push into the repository, then it would
make perfect sense for them to trigger when "push origin :no-such-branch"
were attempted. But if that were the purpose of these hooks, they should
also trigger when "push origin master" is run and "master" is already at
the right commit, as that is the same kind of no-op -- the pushed into
repository was already up-to-date with respect to the wish of the pusher.

I do not mind, and I do prefer, these hooks to run when somebody deleted
an existing ref that points at a corrupt or non-existent object, as that
is _not_ a no-op but is a meaningful event that has an effect that is
observable from the outside world (e.g. ls-remote).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]