From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:58
"Shawn O. Pearce" [off-list ref] writes:
Alex Riesen [off-list ref] wrote:
quoted
On 3/8/07, Shawn O. Pearce [off-list ref] wrote:
quoted
+# 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.
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:42:58
Junio C Hamano [off-list ref] wrote:
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.
Yes, I think the documentation says something about that... ;-)
We could take stdin to solve that and shell
scripts should be able to handle that as refnames do not contain
shell metacharacters.
Never even occurred to me, because I was trying to keep the hook
interface "simple".
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.
Agree completely. I'm not too worried about it. 1300 ref push is
just not going to really occur in practice; that is just insane.
30 refs, maybe.
--
Shawn.
On Thu, 8 Mar 2007 04:13:13 -0500 Shawn O. Pearce wrote:
Junio C Hamano [off-list ref] wrote:
[...]
quoted
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.
Agree completely. I'm not too worried about it. 1300 ref push is
just not going to really occur in practice; that is just insane.
30 refs, maybe.
It is not completely insane - e.g., the current klibc repository
already contains 338 tags. Being unable to use "git push --tags" to
an initially empty repository does not look good.
So could you please switch to passing refs through stdin while we
still can do it without breaking public interfaces?
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:58
On 3/8/07, Junio C Hamano [off-list ref] wrote:
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.
I'm not too worried about linux. It wont have any problems
even if you supply megabytes of arguments (if someone will
really need such lists, he can increase MAX_ARG_PAGES
and be done with it).
The proprietary OS' will have the problem, though. And far sooner
than 1300 refs (w2k has only 32767 bytes for command line).
Besides, don't overestimate peoples readiness to be careful
about reference names. I would expect reference names over
100 bytes in length to happen regularly (generated from file names
appended with a timestamp, for example).
Maybe provide this hooks with simply formatted list on stdin? I.e.
<old-ref> <new-ref> <ref-name> LF
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:42:58
Alex Riesen [off-list ref] wrote:
The proprietary OS' will have the problem, though. And far sooner
than 1300 refs (w2k has only 32767 bytes for command line).
Besides, don't overestimate peoples readiness to be careful
about reference names. I would expect reference names over
100 bytes in length to happen regularly (generated from file names
appended with a timestamp, for example).
Cygwin's lifted that argument handling to be unlimited. But yes,
the point holds, not all OSen will do well with long ref names
and a lot of refs (such as in an initial push of a very verbosely
named project).
Maybe provide this hooks with simply formatted list on stdin? I.e.
<old-ref> <new-ref> <ref-name> LF
Yea, exactly what I was thinking. Easily read on stdin using 'read'
in shell, or in Perl, or, in C, or in ... ;-)
--
Shawn.
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:58
On 3/8/07, Shawn O. Pearce [off-list ref] wrote:
quoted
The proprietary OS' will have the problem, though. And far sooner
than 1300 refs (w2k has only 32767 bytes for command line).
Besides, don't overestimate peoples readiness to be careful
about reference names. I would expect reference names over
100 bytes in length to happen regularly (generated from file names
appended with a timestamp, for example).
Cygwin's lifted that argument handling to be unlimited.
Actually, it didn't at all. Cygwin conveniently forgets that not all
programs use cygwin1.dll. Cygwin is just the wrong place
were the problems of windows stupidity have to be fixed,
and so it does not fix them.
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:42:59
Sergey Vlasov [off-list ref] wrote:
On Thu, 8 Mar 2007 04:13:13 -0500 Shawn O. Pearce wrote:
quoted
Agree completely. I'm not too worried about it. 1300 ref push is
just not going to really occur in practice; that is just insane.
30 refs, maybe.
It is not completely insane - e.g., the current klibc repository
already contains 338 tags. Being unable to use "git push --tags" to
an initially empty repository does not look good.
So could you please switch to passing refs through stdin while we
still can do it without breaking public interfaces?
Fixed with my latest 8 patch series. We now pass the ref data
to the new {pre,post}-receive hooks by stdin, rather than as
command line arguments.
Thanks for the reality check. ;-)
--
Shawn.