Re: [PATCHv1 3/3] git-p4: fixing --changes-block-size handling

2015-06-07 Thread Luke Diamand
On 07/06/15 17:33, Lex Spoon wrote: The implementation looks fine, especially given the test cases that back it up. I am only curious why the block size is set to a default of None. To put it as contcretely as possible: is there any expected configuration where None would work but 500 would not?

Re: [PATCHv1 3/3] git-p4: fixing --changes-block-size handling

2015-06-07 Thread Lex Spoon
The implementation looks fine, especially given the test cases that back it up. I am only curious why the block size is set to a default of None. To put it as contcretely as possible: is there any expected configuration where None would work but 500 would not? We know there are many cases of the

[PATCHv1 3/3] git-p4: fixing --changes-block-size handling

2015-06-07 Thread Luke Diamand
The --changes-block-size handling was intended to help when a user has a limited maxscanrows (see p4 group). It used p4 changes -m $maxchanges to limit the number of results. Unfortunately, it turns out that the maxscanrows and maxresults limits are actually applied *before* the -m maxchanges