Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Ramkumar Ramachandra writes:
>>
>>> Junio C Hamano wrote:
Jeff King writes:
> [...]
Thanks. That is one of the reasons why we do not want to see too
many custom test helper functions.
>>>
>>> I noticed that you queued my
Junio C Hamano writes:
> Ramkumar Ramachandra writes:
>
>> Junio C Hamano wrote:
>>> Jeff King writes:
[...]
>>> Thanks. That is one of the reasons why we do not want to see too
>>> many custom test helper functions.
>>
>> I noticed that you queued my original series without modification
Junio C Hamano writes:
> The only reason a topic is queued in 'pu' is to let me not pay
> attention to it, without risking to forget about it completely ;-).
>
> The topics on 'pu' have potential to be a useful change even though
> they are far from ready for 'next'.
That's not "even though" but
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Jeff King writes:
>>> [...]
>> Thanks. That is one of the reasons why we do not want to see too
>> many custom test helper functions.
>
> I noticed that you queued my original series without modification in
> rr/triangle. Should I submit
Jeff King writes:
> On Mon, Apr 01, 2013 at 02:21:22AM +0530, Ramkumar Ramachandra wrote:
>
>> Jeff King wrote:
>> > [...]
>>
>> So, you're saying: don't test compound statements for failure, since
>> anything in the chain could fail and propagate failure. I should only
>> test simple git-foo c
On Mon, Apr 01, 2013 at 02:21:22AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > [...]
>
> So, you're saying: don't test compound statements for failure, since
> anything in the chain could fail and propagate failure. I should only
> test simple git-foo commands for failure?
Right.
Junio C Hamano wrote:
> Jeff King writes:
>> [...]
> Thanks. That is one of the reasons why we do not want to see too
> many custom test helper functions.
I noticed that you queued my original series without modification in
rr/triangle. Should I submit a re-roll with Peff's suggestion
incorpora
Jeff King wrote:
> [...]
So, you're saying: don't test compound statements for failure, since
anything in the chain could fail and propagate failure. I should only
test simple git-foo commands for failure?
> Sometimes it's annoyingly verbose to break down a compound function. But
> I think in th
Jeff King writes:
> Sometimes it's annoyingly verbose to break down a compound function. But
> I think in this case, you can make your tests more robust by just
> checking the affirmative that the ref is still where we expect it to be,
> like:
>
> check_push_result up_repo $the_first_commit hea
On Thu, Mar 28, 2013 at 06:56:36PM +0530, Ramkumar Ramachandra wrote:
> Jeff King (1):
> t5516 (fetch-push): drop implicit arguments from helper functions
>
> Ramkumar Ramachandra (5):
> remote.c: simplify a bit of code using git_config_string()
> t5516 (fetch-push): update test description
Ramkumar Ramachandra writes:
> The changes in this round are:
>
> 1. Peff submitted a patch to squash into [3/6]. Since his patch
>essentially reverts mine, I've blamed him for the change.
>
> 2. Peff suggested a code movement in [5/6] to make things flow more
>naturally.
>
> 3. Jonathan
Hi,
The changes in this round are:
1. Peff submitted a patch to squash into [3/6]. Since his patch
essentially reverts mine, I've blamed him for the change.
2. Peff suggested a code movement in [5/6] to make things flow more
naturally.
3. Jonathan suggested a better test description in [
12 matches
Mail list logo
