Re: [PATCH] Split sample update hook into post-receive hook

From: Junio C Hamano <junkio@cox.net>
Date: Mar 8, 2007, 09:06 UTC
Message-ID: <7vy7m8aytt.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070308083317.GB30289@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

Show 13 quoted lines

> Alex Riesen <raa.lkml@gmail.com> wrote:
>> On 3/8/07, Shawn O. Pearce <spearce@spearce.org> wrote:
>> >+# Called by git-receive-pack with arguments:
>> >+#    (refname sha1-old sha1-new)+
>> > #
>> 
>> What do you do if this breaks because of too many refs passed?
>
> Die a horrible horrible death?
>
> That's certainly a problem in receive-pack.  It should (somehow)
> break long invocations up, much like what xargs winds up doing.
> Problem is that limit is OS dependent... so uh, yea...

I suspect that it is deeper than that. Think about why having "everything at once" is better than "one at a time".

Potentially you could have a rule that says "these should be updated together" (or the other way around). If you split the set of refs at arbitrary limit, like xargs does, you would lose that advantage. We could take stdin to solve that and shell scripts should be able to handle that as refnames do not contain shell metacharacters.

But this is only true if you want to make it really nice. I personally feel that nobody would scream if pushing 1300 refs at once (4K pages and MAX_ARG_PAGES at 32 would give 128K for **argv and its strings, and one ref's worth of data is two 40-digit hex plus refname, roughly 100-byte per ref) is not supported and always failed.