(nobody) writes:
>Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Pat Thoyts <patthoyts@xxxxxxxxxxxxxxxxxxxxx> 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
--
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