Re: [PATCH] Teach/Fix pull/fetch -q/-v options

["Tuncer Ayaz" <tuncer.ayaz@gmail.com>]

On Sat, Nov 1, 2008 at 6:23 PM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
> On Tue, Oct 28, 2008 at 4:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Nanako Shiraishi <nanako3@lavabit.com> writes:
>>
>>> Quoting Tuncer Ayaz <tuncer.ayaz@gmail.com>:
>>>
>>>> After fixing clone -q I noticed that pull -q does not do what
>>>> it's supposed to do and implemented --quiet/--verbose by
>>>> adding it to builtin-merge and fixing two places in builtin-fetch.
>>>
>>> Junio, may I ask what the status of this patch is? Maybe the patch was
>>> lost in the noise? The commit log message is written very differently from
>>> existing commits in the history of git, and I am thinking that maybe that is
>>> why you did not like the whole patch? Or is it lack of any test script?
>>
>> Well, perhaps you've been with us long enough to get too picky like
>> myself, but this was genuinely lost in the noise and my scrambling to get
>> back to normal.  We do not typically say "I did this, I did that", but the
>> first paragraph in Tuncer's message is perfectly fine.  I would probably
>> liked the second paragraph better if it were after --- lines (it is more
>> about the possible enhancements in other areas, and does not belong to the
>> commit log message for this change), but it is not a grave enough offence
>> to get the patch rejected.
>
> Should I resend the patch with a short and simple commit message
> like the following?
> --8<--
> Implement git-pull --quiet and --verbose by adding the
> options to git-pull and fixing verbosity handling in git-fetch.
> -->8--
>
>> The patch itself looks Ok; the lack of test script additions does indeed
>> bother me somewhat, but it is not too big a deal.
>
> I took a look at t/ and am not quite sure whether I should test -v/-q
> by analyzing stdout output's length & content.
>
> I think testing -q and -v makes more sense on a global and not
> git-pull or git-fetch level. For that to be possible I envision building
> common verbosity-based logging functions/macros.
>
> I don't like the idea of scanning stdout for length or content as
> long as we're not sure that all errors and warnings are sent
> to stderr and stdout is for info and verbose only.
>
>> P.S. We are having fun at GitTogether'08 in the first half of this week,
>> so please expect slower response than usual.
>

Please see my next patch revision arriving here in a moment.