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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]