Find the size of git push in pre-receive hook

Find the size of git push in pre-receive hook

[manigandans]

Hi,

I want to restrict the size of the push on the git remote repository. How
can I find the size of the push in pre-receive hook?

Thanks a lot in advance.

Best regards,
Manigandan S.


--
View this message in context: http://git.661346.n2.nabble.com/Find-the-size-of-git-push-in-pre-receive-hook-tp6962141p6962141.html
Sent from the git mailing list archive at Nabble.com.

Re: Find the size of git push in pre-receive hook

[Magnus Bäck]

On Friday, November 04, 2011 at 10:20 CET,
     manigandans <etc.mani@gmail.com> wrote:

> I want to restrict the size of the push on the git remote repository.
> How can I find the size of the push in pre-receive hook?

What does "size of the push" mean to you? Number of bytes transmitted
over the wire? Number of commits pushed? Number of refs updated? Number
of files modified? Number of lines modified? Something else?

-- 
Magnus Bäck                   Opinions are my own and do not necessarily
SW Configuration Manager      represent the ones of my employer, etc.
Sony Ericsson

Re: Find the size of git push in pre-receive hook

[Junio C Hamano]

manigandans <etc.mani@gmail.com> writes:

> I want to restrict the size of the push on the git remote repository. How
> can I find the size of the push in pre-receive hook?

You don't.

What are you trying to solve?

The thing is, by the time pre-receive-hook is run, the packs have already
been transferred to the destination. Otherwise pre-receive-hook cannot do
its primary task of inspecting the history the push is trying to update
the refs with and allow or deny the ref updates.

Presumably you could run "git rev-list --objects" between the values of
refs before and after the proposed updates, sum up their sizes and reject
the push when the push adds too much data for your liking, and the next gc
will clean things up, but if your goal is to cap the maximum disk quota
including the transient use during the time pre-receive-hook is run, it
would not help.

Re: Find the size of git push in pre-receive hook

[Junio C Hamano]

Manigandan S <etc.mani@gmail.com> writes:

> Let me explain it in detail, if I was not clear.

Do not top-post on this list.

You said you wanted to restrict the size of a push, but what you are
trying is to restrict the size of a repository after a push. If accepting
this push will result in your repository go over the quota, the push will
be denied. Otherwise the push will be accepted.

If that is the case, how much the resulting repository weighs is what you
are trying to measure, not the size of _this_ push, i.e. the amount of
additional data this push will introduce, and "du -s" for the repository
inside pre-receive-hook is the way to do so.

Re: Find the size of git push in pre-receive hook

[Jeff King]

On Sun, Nov 06, 2011 at 09:42:37PM -0800, Junio C Hamano wrote:

> Manigandan S <etc.mani@gmail.com> writes:
> 
> > Let me explain it in detail, if I was not clear.
> 
> Do not top-post on this list.
> 
> You said you wanted to restrict the size of a push, but what you are
> trying is to restrict the size of a repository after a push. If accepting
> this push will result in your repository go over the quota, the push will
> be denied. Otherwise the push will be accepted.
> 
> If that is the case, how much the resulting repository weighs is what you
> are trying to measure, not the size of _this_ push, i.e. the amount of
> additional data this push will introduce, and "du -s" for the repository
> inside pre-receive-hook is the way to do so.

I'm not sure even "du -s" is a good method. That will tell you how big
this push is right _now_, which is at least a maximum. But most commits,
when packed with other commits, will take up a fraction of that space
due to deltas.

So you might receive a 100K thin pack on the network that git will
explode to a 5 megabyte full pack on disk. Next time you repack, it will
only increase the size of your existing packed data by 100K or so.

If receive-pack actually measured the incoming pack bytes in the thin
pack, that would probably be a more accurate guess (but again, it's
still just a guess).

-Peff