From: <rsbecker@nexbridge.com>
To: "'Chris Packham'" <judge.packham@gmail.com>,
"'GIT'" <git@vger.kernel.org>
Subject: RE: Detecting source of a push in a pre-receive hook
Date: Tue, 20 Jan 2026 16:57:20 -0500 [thread overview]
Message-ID: <00ce01dc8a57$c3e19140$4ba4b3c0$@nexbridge.com> (raw)
In-Reply-To: <CAFOYHZDcFJBiZwmposZVGmymmRz1XOaXP8iCRgTDVcsWPTH=6g@mail.gmail.com>
On January 20, 2026 3:46 PM, Chris Packham wrote:
>At $dayjob we're moving from a mix of plain git repositories on a server accessed via
>ssh with a secondary Gerrit server tacked on the side for code review to using the
>Gerrit server as the primary source of truth.
>
>So that people don't have to update origin.url for all their local repositories, we're
>using the Gerrit replication plugin to keep the old server in sync (and will likely do so
>for the foreseeable future).
>We have installed a pre-receive hook for the migrated repositories on the old server
>that rejects pushes from anyone except the user that the replication runs as.
>
>For various reasons we also have a CI system that pushes some things (mostly tags
>but some automated merge commits as well) that runs as the same user. We'd
>really like to be able to have the pre-receive hook reject pushes from the CI system
>but allow them from the Gerrit server. Does the pre-receive hook have any way of
>knowing the source of a push operation?
Let me first say that I have not tried this, but had a similar request on an exotic
platform. Let me then say that the next paragraph contains likely very bad ideas.
You *might* be able to as the OS what the end point is for stdin to your hook. I
am in no way certain that git passes the originating pipe to you, but some systems
may allow this. Some other systems allow you to walk though process context
given the originating pipe, but that's probably less likely to work. Other OS
environments allow you to install hooks into the OS to track pipe operations.
If any of this even slightly works, it is highly unlikely to be portable.
Perhaps a better way (more reliable, easier, portable) is to use a firewall to
block the requests from the CI system to a specific port your git subsystem
is listening on.
My $0.0002 thoughts,
Randall
next prev parent reply other threads:[~2026-01-20 21:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAFOYHZDnXQOcDmzwf1WRpZpNRAs-R2YOBh3ru0mr0ffrMLB=9Q@mail.gmail.com>
2026-01-20 20:45 ` Detecting source of a push in a pre-receive hook Chris Packham
2026-01-20 21:57 ` rsbecker [this message]
2026-01-21 5:27 ` Jeff King
2026-01-21 5:31 ` Jeff King
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='00ce01dc8a57$c3e19140$4ba4b3c0$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=git@vger.kernel.org \
--cc=judge.packham@gmail.com \
/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