git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 22, 2009, 01:47 UTC
Message-ID
<7vws3ru4w8.fsf@alter.siamese.dyndns.org>
In-Reply-To
<7v1vlzvjtg.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 31 quoted lines
> 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.

Show 6 quoted lines
> 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
Previous: Junio C HamanoNext: Pat Thoyts
Message 12 of 19 in “Gitk --all error when there are more than 797 refs in a repository”
  1. Murphy, JohnSep 17, 2009
  2. Re: Gitk --all error when there are more than 797 refs in a repositoryPat Thoyts, Sep 18, 2009
  3. Johannes SixtSep 18, 2009
  4. Re: Gitk --all error when there are more than 797 refs in a repositoryPaul Mackerras, Sep 19, 2009
  5. Murphy, JohnSep 21, 2009
  6. Johannes SixtSep 21, 2009
  7. Murphy, JohnSep 21, 2009
  8. Johannes SixtSep 21, 2009
  9. Pat ThoytsSep 21, 2009
  10. Murphy, JohnSep 22, 2009
  11. Junio C HamanoSep 22, 2009
  12. Junio C HamanoSep 22, 2009
  13. Pat ThoytsSep 22, 2009
  14. Alex RiesenNov 3, 2009
  15. Paul MackerrasNov 3, 2009
  16. Paul MackerrasSep 22, 2009
  17. Junio C HamanoSep 23, 2009
  18. Paul MackerrasNov 3, 2009
  19. Junio C HamanoNov 3, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.