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

2015-06-08 Thread Junio C Hamano
On Mon, Jun 8, 2015 at 11:43 AM, Luke Diamand l...@diamand.org wrote: On 08/06/15 18:18, Junio C Hamano wrote: Lex Spoon l...@lexspoon.org writes: Precisely, Junio, that's what I had in mind. The patch with the two lines deleted LGTM. Thanks, will do. I don't think we're quite there

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

2015-06-08 Thread Junio C Hamano
Lex Spoon l...@lexspoon.org writes: Unless I am reading something wrong, the new_changes variable could be dropped now. It was needed for the -m version for detecting the smallest change number that was returned. Otherwise it looks good to me. Meaning that I should squash this in to 3/3,

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

2015-06-08 Thread Lex Spoon
Precisely, Junio, that's what I had in mind. The patch with the two lines deleted LGTM. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

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

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

2015-06-07 Thread Lex Spoon
Unless I am reading something wrong, the new_changes variable could be dropped now. It was needed for the -m version for detecting the smallest change number that was returned. Otherwise it looks good to me. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message