All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Pat Thoyts <patthoyts@users.sourceforge.net>,
	Johannes Sixt <j.sixt@viscovery.net>, "Murphy\,
	John" <john.murphy@bankofamerica.com>,
	Paul Mackerras <paulus@samba.org>,
	git@vger.kernel.org
Subject: Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
Date: Mon, 21 Sep 2009 18:47:35 -0700	[thread overview]
Message-ID: <7vws3ru4w8.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <7v1vlzvjtg.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Mon\, 21 Sep 2009 18\:39\:55 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Pat Thoyts <patthoyts@users.sourceforge.net> writes:
>
>> commit 7f289ca8370e5e2f9622a4fbc30b934eb97b984f
>> Author: Pat Thoyts <patthoyts@users.sourceforge.net>
>> Date:   Tue Sep 22 00:55:50 2009 +0100
>>
>>     Avoid expanding --all when passing arguments to git log.
>>     There is no need to expand --all into a list of all revisions as
>>     git log can accept --all as an argument. This avoids any
>>     command-line
>>     length limitations caused by expanding --all into a list of all
>>     revision ids.
>>
>>     Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
>>
>> diff --git a/gitk b/gitk
>> index a0214b7..635b97e 100755
>> --- a/gitk
>> +++ b/gitk
>> @@ -241,6 +241,8 @@ proc parseviewrevs {view revs} {
>>
>>      if {$revs eq {}} {
>>         set revs HEAD
>> +    } elseif {$revs eq "--all"} {
>> +        return $revs
>>      }
>
> That looks like an ugly hack (aka sweeping the issue under the rug).
>
> What if there are many tags and the user used --tags?  Don't you have
> exactly the same problem?  Likewise, what if $revs were "..master"?

Sorry, I meant "--all --not master" to grab all the topics not merged to
master yet.

But my point still stands.

I do not understand what computed values storedin vposids() and vnegids()
arrays are being used in the other parts of the program that rely on this
function to do what it was asked to do, but if this patch can ever be
correct, a much simpler solution to make this function almost no-op and
always return {} (empty array ret is initialized to) would be an equally
valid fix, no?  And my gut feeling tells me that such a change to make
this function a no-op  _can't_ be a valid fix.

> The right approach would be to understand what limit it is busting (it is
> not likely to be the command line length limit for this particular "exec",
> as it only gets "git" "rev-parse" "--all") first, and then fix that.
>
>>      if {[catch {set ids [eval exec git rev-parse $revs]} err]} {
>>         # we get stdout followed by stderr in $err

  reply	other threads:[~2009-09-22  1:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-17 19:07 Gitk --all error when there are more than 797 refs in a repository Murphy, John
2009-09-18 14:06 ` [PATCH] " Pat Thoyts
2009-09-18 15:16   ` Johannes Sixt
2009-09-19  0:07   ` Paul Mackerras
2009-09-21 14:02     ` Murphy, John
2009-09-21 14:09       ` Johannes Sixt
2009-09-21 14:11         ` Murphy, John
2009-09-21 15:59           ` Johannes Sixt
2009-09-21 23:56             ` Pat Thoyts
2009-09-22  1:23               ` Murphy, John
2009-09-22  1:39               ` Junio C Hamano
2009-09-22  1:47                 ` Junio C Hamano [this message]
2009-09-22 22:48                   ` Pat Thoyts
2009-11-03 10:04                 ` Alex Riesen
2009-11-03 10:41                   ` Paul Mackerras
2009-09-22 23:30               ` Paul Mackerras
2009-09-23  0:02                 ` Junio C Hamano
2009-11-03  9:40                   ` Paul Mackerras
2009-11-03 14:59                     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vws3ru4w8.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=j.sixt@viscovery.net \
    --cc=john.murphy@bankofamerica.com \
    --cc=patthoyts@users.sourceforge.net \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.