On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty <sitar...@gmail.com> wrote:
> On 08/14/2013 07:14 AM, Junio C Hamano wrote:
>> Sitaram Chamarty <sitar...@gmail.com> 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
$ perl -e 'print "A" x (262144 * 2)' | wc -c
$ perl -e 'print "A" x (262144 * 2)' | sh -c 'read v; echo "$v"' | wc -c
$ perl -e 'print "A" x (262144 * 2)' | sh -c 'read v; /bin/echo "$v"' | wc -c
sh: /bin/echo: Argument list too long

builtin's argument buffer limit tends to be aligned with the
implementation's lexer buffer limit
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to