On Wed, Aug 14, 2013 at 4:35 AM, Sitaram Chamarty <sitaramc@xxxxxxxxx> wrote:
> On 08/14/2013 12:40 PM, Andres Perera wrote:
>> On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty <sitaramc@xxxxxxxxx> wrote:
>>> On 08/14/2013 07:14 AM, Junio C Hamano wrote:
>>>> Sitaram Chamarty <sitaramc@xxxxxxxxx> writes:
>>>>
>>>>> # all reflog entries that are not on a branch, tag, or remote
>>>>> d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes
>>>>> # all dangling commits not on a branch, tag, or remote
>>>>> d2 = !gitk --date-order $(git fsck | grep "dangling.commit" | cut -f3 -d' ') --not --branches --tags --remotes
>>>>>
>>>>> (Apologies if something like this was already said; I was not following
>>>>> the discussion closely enough to notice)
>>>>
>>>> Yup.
>>>>
>>>> A potential problem is that the output from "log -g --pretty=%H" or
>>>> "fsck | grep dangling" may turn out to be humongous. Other than
>>>> that, they correctly compute what you want.
>>>
>>> I thought I mentioned that but I can't find my email now so maybe I
>>> didn't.
>>>
>>> In practice though, I find that, bash at least seems happy to take
>>> command lines as long as 7+ million characters long, so with the default
>>> reflog expire times, that should work out to 10,000 commits *per day*.
>>> [Tested with: echo {1000000..1900000} > junk; echo `cat junk` | wc]
>>
>> echo is a builtin in bash, as is the case with other shell implementations
>>
>> builtins may have different limit's than exec()'s ARG_MAX
>>
>> $ getconf ARG_MAX
>> 262144
>> $ perl -e 'print "A" x (262144 * 2)' | wc -c
>> 524288
>> $ perl -e 'print "A" x (262144 * 2)' | sh -c 'read v; echo "$v"' | wc -c
>> 524289
>> $ perl -e 'print "A" x (262144 * 2)' | sh -c 'read v; /bin/echo "$v"' | wc -c
>> sh: /bin/echo: Argument list too long
>> 0
>>
>> builtin's argument buffer limit tends to be aligned with the
>> implementation's lexer buffer limit
>
> Aah; good catch -- I did not know this. Thanks!
>
> My systems show 2621440 on CentOS 6 and 2097152 on Fedora 19, so --
> dividing by 8 (abbrev SHA + space) then by 90, that's still 2900 commits
> *per day* to run past this limit though!
ARG_MAX may also include the process environment, which needs to be
copied over to the new vm
the limit may also include the argv pointer sizes
those calculations based on SHA string length are just approximates
>
> (side note: making a single argument that long seems to have a much
> lower limit than having multiple arguments:
>
> $ /bin/echo `perl -e 'print "A" x (1000000)'` | wc
> -bash: /bin/echo: Argument list too long
> 0 0 0
> $ /bin/echo `perl -e 'print "A " x (1000000)'` | wc
> 1 1000000 2000000
>
> notice that the second one is twice as long in terms of bytes, but it's
> not a single argument).
the behaviour is different in OpenBSD-amd64:
perl -e 'print "A " x ((262144/2)-5)' | env -i sh -c 'unset PATH; read
v; /bin/echo $v' | wc -c
a bigger size and i get E2BIG. if i pass the env or let PATH get
exported, again, i need to reduce the multiplier
apparently Linux is doing copyin() for each argument. that seems
excessive to me :)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html