Git smart http: parsing commit messages in git-receive-pack

Git smart http: parsing commit messages in git-receive-pack

[akos tajti]

Dear All,

we implemented a java servlet around the git-http-backend. This servlet intercepts the requests sent by the git client when pushing. One thing I want to achieve is parsing the commit messages in the pre push phase (request param service==git-receive-pack) and after checking if the commit messages contain a given string reject/accept the request. The problem is that I couldn't find a way of parsing the commit messages in git-receive-pack (I can do this in the post  push phase but in that case I cannot reject the push because the changes are already on the server). Is there a way of getting the commit messages before they're actually on the server so that I can reject the push?

Thanks in advance,
Ákos Tajti

Re: Git smart http: parsing commit messages in git-receive-pack

[Bryan Turner]

On Sat, May 6, 2017 at 5:30 AM, akos tajti <akos.tajti@gmail.com> wrote:
> Dear All,
>
> we implemented a java servlet around the git-http-backend. This servlet intercepts the requests sent by the git client when pushing. One thing I want to achieve is parsing the commit messages in the pre push phase (request param service==git-receive-pack) and after checking if the commit messages contain a given string reject/accept the request. The problem is that I couldn't find a way of parsing the commit messages in git-receive-pack (I can do this in the post  push phase but in that case I cannot reject the push because the changes are already on the server). Is there a way of getting the commit messages before they're actually on the server so that I can reject the push?

The protocol isn't really intended for use to try and parse pack data
before it's spooled to disk. It might be possible, but it's likely to
be brittle (due to things like delta compression, for example).

I believe what you're looking for is a pre-receive hook[1] on your
server. This is how Bitbucket Server (which is also written in Java)
works. It opens a socket on localhost and installs a pre-receive hook
into each repository which uses a Perl script to pipe all of its input
to the listening socket and then read any response from the server
back. After the push has written all of its objects to disk, Git
invokes any pre-receive hooks and passes in all the ref changes. The
Perl script pipes those to the server, which applies whatever checks
are desired and writes any errors or info back to the hook, which then
prints it for Git to use before exiting with the correct status code
(0 to accept the push, 1 to reject it).

This means the objects are on the server, but in Git 2.11 Peff added
"quarantine" functionality which writes those new objects into an
"incoming" directory[2]. That means, while they're on disk, they're
_not_ in the repository itself. If the pre-receive hook rejects the
push, those objects are immediately deleted from disk.

That means if you pair a pre-receive hook with Git 2.11 or newer on
the server, you should be able to achieve what you're looking for.
Once the objects have been written to the quarantine directory, you
can use normal Git commands, like cat-file, rev-list or log, to review
them. If they don't meet your requirements, just reject the push and
Git will delete the objects automatically

Hope this helps!
Bryan Turner

>
> Thanks in advance,
> Ákos Tajti
>

[1]: https://git-scm.com/docs/githooks includes documentation for
pre-receive inputs and outputs
[2]: https://github.com/git/git/blob/master/Documentation/git-receive-pack.txt#L219-L243
includes some additional documentation about the quarantine
environment

Re: Git smart http: parsing commit messages in git-receive-pack

[Junio C Hamano]

Bryan Turner <bturner@atlassian.com> writes:

> That means if you pair a pre-receive hook with Git 2.11 or newer on
> the server, you should be able to achieve what you're looking for.

It probably is worth mentioning that even without the "quarantine"
changes of 2.11, the new objects brought in by a rejected push
cannot be used because they are not reachable from any ref, and will
be discarded as garbage when the next GC run.  So pre-receive should
be sufficient for the purpose of "not accepting" an undesirable
push, with older versions of Git.  You can view the "quarantine"
feature mostly as "quality of implementation" issue.