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

- From: Luke Diamand \<hidden\>
- Date: 2016-06-15 23:05:11 
- List: git
- Page: https://ratatoskr.run/git/2016/06/7657452
- Thread: https://ratatoskr.run/git/2016/06/7657436/t.md

```text
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? We know there
> are many cases of the other way around, and those cases are going to
> send users to StackOverflow to find the right workaround.

I think it was just caution: it's pretty easy to make it fall back to the old non-batched scheme, so if it turns out that there *is* a problem, fewer people will hit the problem and we're less likely to have a paper-bag release.

>
> Dropping the option would also simplify the code in several places.
> The complex logic around get_another_block could be removed, and
> instead there could be a loop from start to mostRecentCommit by
> block_size. Several places that check "if not block_size" could just
> choose the other branch.

Fair point. I'll give it a go and see what happens.

(Plus 500 is a very unnatural number, chosen just because we still place some kind of significance on a chance evolutionary accident that gave our ape ancestors 5 digits on each hand :-)

Luke
```