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

From: Luke Diamand <luke@diamand.org>
Date: Jun 7, 2015, 17:06 UTC
Message-ID: <55747A05.3070704@diamand.org>
In-Reply-To: <CALM2SnbVY1baAONo3o2gb2NS+rDSsyhkPffP5EJZKU1MDA7q9w@mail.gmail.com>

On 07/06/15 17:33, Lex Spoon wrote:

Show 6 quoted lines

> 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.

Show 6 quoted lines

>
> 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