Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
- From
Pat Thoyts <patthoyts@users.sourceforge.net>
- Date
- Sep 22, 2009, 22:48 UTC
- Message-ID
- <87y6o6a944.fsf@users.sourceforge.net>
- In-Reply-To
- <7vws3ru4w8.fsf@alter.siamese.dyndns.org>
(nobody) writes:
Show 13 quoted lines
>Junio C Hamano <gitster@pobox.com> writes: > >> Pat Thoyts <patthoyts@users.sourceforge.net> writes: >> >> 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.
Not exactly. The problem is that the call to parseviewrevs will expand
--all into a tcl list containing all the revision ids. We can do some
testing if we dig into this with the tcl console:
% llength [set revs [parseviewrevs {} --all]]
1001
% string length $revs
41040
In start_rev-list this list gets added to the command line for git-log
in the $args variable. This is always going to exceed windows'
commandline limit (32k).Some testing shows that a number of rev-parse arguments do not get expanded into a list of ids. All these can be ignored. But --all, --tags and --branches do. Maybe --remotes as well. These arguments are accetable to git-log so it looks to me like they can be left as-is.
The vposids and vnegids arrays are getting used for something though. So the patch is not complete. They appear to be caching the set of revisions present in the current view for use in updatecommits to do something.
So - needs more work.
-- Pat Thoyts http://www.patthoyts.tk/ PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD